From nobody Fri Feb 5 09:10:55 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D35BE1B3BB3; Fri, 5 Feb 2016 09:10:52 -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: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160205171052.27534.55663.idtracker@ietfa.amsl.com> Date: Fri, 05 Feb 2016 09:10:52 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-sla-exchange-07.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: Fri, 05 Feb 2016 17:10:53 -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 : Inter-domain SLA Exchange Attribute Authors : Shitanshu Shah Keyur Patel Sandeep Bajaj Luis Tomotaki Mohamed Boucadair Filename : draft-ietf-idr-sla-exchange-07.txt Pages : 30 Date : 2016-02-05 Abstract: Network administrators typically enforce Quality of Service (QoS) policies according to Service Level Agreement (SLA) with their providers. The enforcement of such policies often relies upon vendor-specific configuration language. Both learning of SLA, either thru SLA documents or via some other out-of-band method, and translating them to vendor specific configuration language is a complex, often manual, process and prone to errors. This document specifies an optional transitive attribute to signal SLA parameters in-band, across administrative boundaries (considered as Autonomous Systems (AS)), thus simplifying and facilitating some of the complex provisioning tasks in situations where BGP is available as a routing protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-sla-exchange-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-sla-exchange-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 5 12:04:24 2016 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 C510D1ACE51; Fri, 5 Feb 2016 12:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.257 X-Spam-Level: X-Spam-Status: No, score=-96.257 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 wKakfsWacn3R; Fri, 5 Feb 2016 12:04:21 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 E30091ACE4C; Fri, 5 Feb 2016 12:04:20 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: Date: Fri, 5 Feb 2016 15:04:03 -0500 Message-ID: <002401d16050$5cba52e0$162ef8a0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01D16026.73E58360" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdFgTvATc4xhvDpqSdanGhK2hw1rbA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-idr-sla-exchange@ietf.org Subject: [Idr] WG LC missed IPR Statements - 1 WG LC for IPR 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, 05 Feb 2016 20:04:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0025_01D16026.73E58360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit After a long review/edit cycle after WG LC, draft-ietf-idr-sla-exchange-07.txt is ready to go to the IESG. You can see the resulting text at: https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ However, in checking the IPR statements the IDR chairs missed two steps in the process: Step 1: There was IPR declared in the mail message regarding draft-ietf-idr-sla-exchange-03: https://mailarchive.ietf.org/arch/msg/idr/rPvMVsFcM4xOm1Vz_HNdAM3P250 This IPR is unusual in that the holder of the patent is not one of the authors of the draft as the link shows: https://datatracker.ietf.org/ipr/search/?id=draft-ietf-idr-sla-exchange &submit=draft As a WG Chairs, we must ask again if the WG wants to approve the draft in the face of this patent. This begins a 1 Week IPR LC where the WG must send positive indications they wish to send this document to WG LC. This message was sent prior to the WG LC (1/19/2015 to 2/5/2015), but no specific mention was made. Due to IPR policy, we must get a positive affirmation that the WG LC wants to adopt this work. All authors to the draft MUST respond to this IPR call or we cannot forward this to the IESG for publication. Details on these implementations of draft-ietf-idr-sla-exchange are at: https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-sla-exchange%20i mplementations Step 2: three of the authors did not declare IPR on-list: Keyur Patel, S. Bajaj, L. Tomotaki These authors need to declare if they know if additional IPR. Thank you for your patience, Sue Hares and John Scudder ------=_NextPart_000_0025_01D16026.73E58360 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

After a = long review/edit cycle after WG LC, draft-ietf-idr-sla-exchange-07.txt = is ready to go to the IESG.   You can see the resulting text = at:

 ht= tps://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/

 

However, in checking the IPR statements the IDR chairs = missed two steps in the process:

 

Step = 1:  There was IPR declared in the mail message regarding =  draft-ietf-idr-sla-exchange-03:  https://mailarchive.ietf.org/arch/msg/idr/rPvMVsFcM4xOm1Vz_HNdAM3P2= 50

 

This IPR is unusual in that the holder of the patent = is not one of the authors of the draft as the link shows: =

https://datatracker.ietf.org/ipr/search/?id=3D= draft-ietf-idr-sla-exchange&submit=3Ddraft

 

As a WG = Chairs, we must ask again if the WG wants to approve the draft in the = face of this patent.  This begins a 1 Week IPR LC where the WG must = send positive indications they wish to send this document to WG LC. =  This message was sent prior to the WG LC (1/19/2015 to 2/5/2015), = but no specific mention was made.  Due to IPR policy, we must get a = positive affirmation that the WG LC wants to adopt this work.  All = authors to the draft MUST respond to this IPR call or we cannot forward = this to the IESG for publication.

 

Details on = these implementations of draft-ietf-idr-sla-exchange are at: =

https://trac.tools.ietf.org/wg/idr/trac/wiki/d= raft-ietf-idr-sla-exchange%20implementations

 

 

Step = 2:  three of the authors did not declare IPR on-list:  Keyur = Patel,  S. Bajaj,  L. Tomotaki

 

These = authors need to declare if they know if additional IPR.

 

Thank you = for your patience,

 

Sue Hares = and John Scudder  

------=_NextPart_000_0025_01D16026.73E58360-- From nobody Fri Feb 5 21:21:55 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 717F91A92B6; Fri, 5 Feb 2016 21:21:54 -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: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160206052154.26978.97882.idtracker@ietfa.amsl.com> Date: Fri, 05 Feb 2016 21:21:54 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-sla-exchange-08.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, 06 Feb 2016 05:21:54 -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 : Inter-domain SLA Exchange Attribute Authors : Shitanshu Shah Keyur Patel Sandeep Bajaj Luis Tomotaki Mohamed Boucadair Filename : draft-ietf-idr-sla-exchange-08.txt Pages : 30 Date : 2016-02-05 Abstract: Network administrators typically enforce Quality of Service (QoS) policies according to Service Level Agreement (SLA) with their providers. The enforcement of such policies often relies upon vendor-specific configuration language. Both learning of SLA, either thru SLA documents or via some other out-of-band method, and translating them to vendor specific configuration language is a complex, often manual, process and prone to errors. This document specifies an optional transitive attribute to signal SLA parameters in-band, across administrative boundaries (considered as Autonomous Systems (AS)), thus simplifying and facilitating some of the complex provisioning tasks in situations where BGP is available as a routing protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-sla-exchange-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-sla-exchange-08 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 Feb 6 15:53:35 2016 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 CB6F91A87A3; Sat, 6 Feb 2016 15:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lg5wjOHYRO1V; Sat, 6 Feb 2016 15:53:31 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09551A8796; Sat, 6 Feb 2016 15:53:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20315; q=dns/txt; s=iport; t=1454802810; x=1456012410; h=from:to:cc:subject:date:message-id:mime-version; bh=8wPJaXaRJGf5I+KlK+hgDxopqUiWnYZKGTg6j5dixQs=; b=Rws1K2g9BIhPZVkp0mPcpYt6L/b2KaiTw2ECz2D4Ddl7t245Y6TuuNI7 aYz3Mkf/jknBC1FncAeRMA+CnuzBbI3uqvz6MAJ82hIeQQC01Wo9KuWhq zt0A/3oB/WCyWX/4ytUvJp8q/x9rYN1mQe+Roo7kGmhtmo5ndh3KpRO+1 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWBQAth7ZW/49dJa1egm5MgT8GiFWyf?= =?us-ascii?q?IYNgSQ7EQEBAQEBAQF/C4RCAgR5EgEIPzkUEwQOBRSIB74kAQEBAQYBAQEBAQE?= =?us-ascii?q?ahhIBhDaEGoRSBZJuhAcBjU+BW4RDiFWFboR+g1EBNiyCAxmBSGqHGgUCNnwBA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos; i="5.22,407,1449532800"; d="scan'208,217"; a="70895113" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2016 23:53:29 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u16NrTcl030227 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 6 Feb 2016 23:53:29 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 6 Feb 2016 17:53:28 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Sat, 6 Feb 2016 17:53:28 -0600 From: "Alvaro Retana (aretana)" To: "draft-ietf-idr-ix-bgp-route-server@ietf.org" Thread-Topic: [Idr] AD Review of draft-ietf-idr-ix-bgp-route-server-09 Thread-Index: AQHRYTmT70VvWdDyrUy3K4QkMQ61Uw== Date: Sat, 6 Feb 2016 23:53:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.21.127] Content-Type: multipart/alternative; boundary="_000_D2DBC73610DD13aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr-chairs@ietf.org" , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-ix-bgp-route-server-09 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, 06 Feb 2016 23:53:34 -0000 --_000_D2DBC73610DD13aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 12/11/15, 3:15 PM, "Idr on behalf of Alvaro Retana (aretana)" on behalf of aretana@cisco.com> wrote: Hi! It's been almost two months since I sent this review, but have received no = answer. :-( Alvaro. Hi! I just finished reading this document. Please find my comments below. As you can see, the comments I labeled as Major are mostly related to secur= ity considerations, where I think there's more to add, and clarity with res= pect to the behavior in RFC4271. I don't think that any of the comment wil= l be hard to address. I will wait for your comments/discussion and/or an update before starting t= he IETF Last Call. Thanks! Alvaro. Major: 1. Should this document be marked as updating rfc4271? There are severa= l places in Section 2 where the behavior is different than what is specifie= d in rfc4271. Given that the route server functionality is an optional enh= ancement, I don't think this document should be marked as updating rfc4271 = (I.e. It changes the behavior only for the functionality specified here). = I'm assuming the authors/WG agree since there is no indication of an update= . Please include a clear statement (maybe in the Introduction) to the fact= that the mechanism is optional. 2. Section 2.1. (Client UPDATE Messages). "The route server SHOULD forwa= rd UPDATE messages where appropriate=85to its clients." When is it appropr= iate? I'm guessing that you mean something like "where local policy permit= s".. Please be clear. 3. Section 2.2.2. (AS_PATH Attribute) Not prepending the route server's= AS_PATH brings up a couple of issues/questions: * RFC4271 talks about prepending the local ASN (when advertising to = an EBGP peer), and it doesn't mention any exceptions. This document includ= es an exception. Clearly indicate the modifications to Section 5.1.2. (AS_= PATH) of RFC4271. * Section 6.3. (UPDATE Message Error Handling) of rfc4271 says that = when an "=85UPDATE message is received from an external peer, the local sys= tem MAY check whether the leftmost=85AS in the AS_PATH attribute is equal t= o the autonomous system number of the peer that sent the message", and MUST= send a NOTIFICATION if it doesn't. * Please be explicit about the required behavior for both the rou= te server, and the clients. * Even though this check is optional in RFC4271, mandating that i= s not be done could be interpreted as a security issue. Please include som= e text around it (and mitigation) in the Security Considerations section. * Independent of the check, not including an ASN in the AS_PATH coul= d (in the general case) result in loops; which I also interpret as a potent= ial security issue. Please include some text about this too =97 a mitigati= on option is clearly to not check the first ASN only when known route serve= rs are peers. 4. Section 2.2.4. (Communities Attributes) says that Communities "SHOULD= NOT be modified, processed or removed. However, if such an attribute is i= ntended for processing by the route server itself, it MAY be modified or re= moved." How does the route server know if the sender intended for a commun= ity to be processed by it, or not? Please add details. 5. Section 3. (Security Considerations) * Besides the points above, because clients rely on the route server= to implement outbound route filtering for them, there can be a privacy iss= ue/route leak scenario where the route server can send routes to clients th= at it shouldn't have. Not much can be done to mitigate this because it wil= l mostly be due to a bad implementation or simply a "bad operator". * You should point at relevant sections of RFC7454. 6. Minor: 1. Please be consistent: * s/exterior BGP/external BGP..or even just EBGP (yes, a nit..but th= at's how rfc4271 calls EBGP) * s/best path selection process/Decision Process * s/IX/IXP 2. Section 2.2.3. (MULTI_EXIT_DISC Attribute) specifically calls out the= MED, but you already said in Section 2.2. (Attribute Transparency) that al= l optional attributes "SHOULD NOT be updated by the route server=85and SHOU= LD be passed on to other route server clients." Is there anything special = about the MED that I'm missing? If not, then you should be able to delete = the section. 3. In Section 2.3.1. (Path Hiding on a Route Server) policy implementati= on is described in terms of outbound route filtering. The description of t= he example says that if "AS1's policy prevents AS2's path from being accept= ed, then AS1 would never receive a path to this prefix". To be consistent = with the outbound filtering description, you might want to change that text= to something like "AS2's policy prevents AS1 from receiving the path, =85"= . 4. Section 2.3.2.2. (Advertising Multiple Paths) says that if the route = server sends "more than a single path to a route server client,=85the path = hiding problem described in Section 2.3.1 would disappear." That statement= is true, but only if all the paths are propagated, not just "more than a s= ingle" one. [You do talk about that in 2.3.2.2.1, but not the general case.= ] 5. Section 2.3.2.2.2. (BGP ADD-PATH Approach) * This section says that if "the route server client propagates mult= iple paths for the same prefix to the route server, then this could potenti= ally cause the propagation of inactive, invalid or suboptimal paths to the = route server, thereby causing loss of reachability to other route server cl= ients." I can see how suboptimal (=3D non best) paths can be propagated by= the clients, but what about invalid? * To be consistent, there's no such thing as send-only and receive-o= nly modes negotiated with ADD-PATH. For the result in the text (having onl= y the route server send), the route server should advertise the Send/Receiv= e field in the ADD_PATH capability set to 2 (only able to send). It doesn'= t matter what the client sets the value to (as long as it is not 2). 6. References: I think the following can be made Informational: RFC1997= , RFC4360 Nits: 1. Given that Section 2.3 is "included for information purposes only", y= ou might want to consider making it an Appendix. 2. Section 2.3.3. (Implementation Suggestions) seems superfluous to me. --_000_D2DBC73610DD13aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0BE5A5B41BA5874BBE4DC8A2A2ABBC21@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 12/11/15, 3:15 PM, "Idr on behalf of Alvaro Retana (aretana)&q= uot; <idr-bounces@ietf.org o= n behalf of aretana@cisco.com> wrote:

Hi!

It's been almost two months since I sent this review, but have receive= d no answer. :-(

Alvaro.

Hi!

I just finished reading this document.  Please find my comments below.=

As you can see, the comments I labeled as Major are mostly related to secur= ity considerations, where I think there's more to add, and clarity with res= pect to the behavior in RFC4271.  I don't think that any of the commen= t will be hard to address.

I will wait for your comments/discussion and/or an update before starting t= he IETF Last Call.

Thanks!

Alvaro.


Major:
  1. Should this document be marked as updating rfc4271?  There are several= places in Section 2 where the behavior is different than what is specified= in rfc4271.  Given that the route server functionality is an optional= enhancement, I don't think this document should be marked as updating rfc4271 (I.e. It changes the behavior only fo= r the functionality specified here).  I'm assuming the authors/WG agre= e since there is no indication of an update.  Please include a clear s= tatement (maybe in the Introduction) to the fact that the mechanism is optional.
  2. Section 2.1. (Client UPDATE Messages). "The route server SHOULD f= orward UPDATE messages where appropriate=85to its clients."  When= is it appropriate?  I'm guessing that you mean something like "w= here local policy permits"..  Please be clear.
  3. Section 2.2.2. (AS_PATH Attribute)  Not prepending the route serv= er's AS_PATH brings up a couple of issues/questions:
    • RFC4271 talks about prepending the local ASN (when advertising to an EBGP p= eer), and it doesn't mention any exceptions.  This document includes a= n exception.  Clearly indicate the modifications to Section 5.1.2= . (AS_PATH) of RFC4271.
    • Section 6.3. (UPDATE Message Error H= andling) of rfc4271 says that when an "=85UPDATE message is received f= rom an external peer, the local system MAY check whether the leftmost=85AS in the AS_PATH attribute is equal to the autonomous system number of the peer that sent= the message&= quot;, and MUST send a NOTIFICATION if it doesn't.
      • Please be explicit ab= out the required behavior for both the route server, and the clients.
        • =
      • Even though this chec= k is optional in RFC4271, mandating that is not be done could be interprete= d as a security issue.  Please include some text around it (and mitiga= tion) in the Security Considerations section.
    • Independent of the check, not in= cluding an ASN in the AS_PATH could (in the general case) result in loops; = which I also interpret as a potential security issue.  Please inc= lude some text about this too =97 a mitigation option is clearly to not check the first ASN only when known route servers are pe= ers.
  4. Section 2.2.4. (Communities Attributes) says that Communities "SHOULD NOT be modifi= ed, processed or removed.  However, if such an attribute is intended for processing by the route server itself, it MAY be modified = or removed."  How does the route server know if the sender intend= ed for a community to be processed by it, or not?  Please add details.
  5. 3. (Security Consid= erations)  
    • Besides the points above, because cli= ents rely on the route server to implement outbound route filtering for the= m, there can be a privacy issue/route leak scenario where the route server = can send routes to clients that it shouldn't have.  Not much can be done to mitigate this because it wil= l mostly be due to a bad implementation or simply a "bad operator"= ;.
    • You should point at rel= evant sections of RFC7454.
Minor:
  1. Please be consistent:
    • s/exterior BGP/external BGP..or even just EBGP (yes, a nit..but that's = how rfc4271 calls EBGP)
    • s/best path selection process/Decision Proc= ess
    • s/IX/IXP
  2. Section 2.2.3. (MULTI_EXIT_DISC Attribute) specificall= y calls out the MED, but you already said in Section 2.2. (Attribute Transparency) that all optional attributes "SHOULD NOT be = updated by the route server=85and SHOULD be passed on to other route <= /font>server clients.&quo= t;  Is there anything special about the MED that I'm missing?  If not, then you should be able to delete the section.
  3. In Section 2.3.1. (Path Hiding on a Route Server) policy implementation is described in terms of outbound route filtering. &= nbsp;The description of the example says that if "AS1's policy prevents AS2's path from being accepted, then AS1 would never receive a path = to this prefix". &nb= sp;To be consistent with the outbound filtering description, you might want= to change that text to something like "AS2's policy prevents AS1 from receiving the path, =85".
  4. Secti= on 2.3.2.2. (Advertising Mult= iple Paths) says that if the route server sends "more than a single path to a route server client,=85the path= hiding problem described in Section 2.3.1 would disappear."  That statement i= s true, but only if all the paths are propagated, not just "more than a single" one. [You do talk about that in 2.3.2.= 2.1, but not the general case.]
  5. Section 2.3.2.2.2. (BGP ADD-PATH Approach) 
    • This section says that if "the route server client=  propagates m= ultiple paths for the same prefix to the route server, then this could potentially cause the propagation of inactive, invalid or suboptimal paths t= o the route server, thereby causing loss of reachability to other route server clients."  I can see how suboptimal (=3D non best) paths can be = propagated by the clients, but what about invalid?
    • To be consistent, there's no such thing as send-on= ly and receive-only modes negotiated with ADD-PATH.  For the result in= the text (having only the route server send), the route server should adve= rtise the Send/Receive field in the ADD_PATH capability set to 2 (only able to send).  It doesn't = matter what the client sets the value to (as long as it is not 2).
  6. References:  I think the fo= llowing can be made Informational: RFC1997, RFC4360
Nits:
  1. Given that Section 2.3 is "included for information pu= rposes only", you might want to consider making it an Appendix.
    2. Section 2.3.3. (Implementation Suggestions) seems superfluous to me.
 --_000_D2DBC73610DD13aretanaciscocom_-- From nobody Sat Feb 6 16:03:57 2016 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 C88B61A87A7; Sat, 6 Feb 2016 16:03:54 -0800 (PST) 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 KH2iUUXb8HWH; Sat, 6 Feb 2016 16:03:52 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::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 306EF1A8797; Sat, 6 Feb 2016 16:03:51 -0800 (PST) X-Envelope-To: idr@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u1703iBI020930 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Feb 2016 00:03:45 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56B689DD.1090808@foobar.org> Date: Sun, 07 Feb 2016 00:03:41 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "Alvaro Retana (aretana)" References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "idr-chairs@ietf.org" , "idr@ietf.org" , Susan Hares , "draft-ietf-idr-ix-bgp-route-server@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-ix-bgp-route-server-09 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, 07 Feb 2016 00:03:54 -0000 Hi Alvaro, Yeah, sorry about this. High work load and we weren't expecting a bunch of major comments at this stage. We'll get it sorted shortly. Nick Alvaro Retana (aretana) wrote: > On 12/11/15, 3:15 PM, "Idr on behalf of Alvaro Retana (aretana)" on behalf of aretana@cisco.com> wrote: > > Hi! > > It's been almost two months since I sent this review, but have received no answer. :-( > > Alvaro. > > Hi! > > I just finished reading this document. Please find my comments below. > > As you can see, the comments I labeled as Major are mostly related to security considerations, where I think there's more to add, and clarity with respect to the behavior in RFC4271. I don't think that any of the comment will be hard to address. > > I will wait for your comments/discussion and/or an update before starting the IETF Last Call. > > Thanks! > > Alvaro. > > > Major: > > 1. Should this document be marked as updating rfc4271? There are several places in Section 2 where the behavior is different than what is specified in rfc4271. Given that the route server functionality is an optional enhancement, I don't think this document should be marked as updating rfc4271 (I.e. It changes the behavior only for the functionality specified here). I'm assuming the authors/WG agree since there is no indication of an update. Please include a clear statement (maybe in the Introduction) to the fact that the mechanism is optional. > 2. Section 2.1. (Client UPDATE Messages). "The route server SHOULD forward UPDATE messages where appropriate…to its clients." When is it appropriate? I'm guessing that you mean something like "where local policy permits".. Please be clear. > 3. Section 2.2.2. (AS_PATH Attribute) Not prepending the route server's AS_PATH brings up a couple of issues/questions: > * RFC4271 talks about prepending the local ASN (when advertising to an EBGP peer), and it doesn't mention any exceptions. This document includes an exception. Clearly indicate the modifications to Section 5.1.2. (AS_PATH) of RFC4271. > * Section 6.3. (UPDATE Message Error Handling) of rfc4271 says that when an "…UPDATE message is received from an external peer, the local system MAY check whether the leftmost…AS in the AS_PATH attribute is equal to the autonomous system number of the peer that sent the message", and MUST send a NOTIFICATION if it doesn't. > * Please be explicit about the required behavior for both the route server, and the clients. > * Even though this check is optional in RFC4271, mandating that is not be done could be interpreted as a security issue. Please include some text around it (and mitigation) in the Security Considerations section. > * Independent of the check, not including an ASN in the AS_PATH could (in the general case) result in loops; which I also interpret as a potential security issue. Please include some text about this too — a mitigation option is clearly to not check the first ASN only when known route servers are peers. > 4. Section 2.2.4. (Communities Attributes) says that Communities "SHOULD NOT be modified, processed or removed. However, if such an attribute is intended for processing by the route server itself, it MAY be modified or removed." How does the route server know if the sender intended for a community to be processed by it, or not? Please add details. > 5. Section 3. (Security Considerations) > * Besides the points above, because clients rely on the route server to implement outbound route filtering for them, there can be a privacy issue/route leak scenario where the route server can send routes to clients that it shouldn't have. Not much can be done to mitigate this because it will mostly be due to a bad implementation or simply a "bad operator". > * You should point at relevant sections of RFC7454. > 6. > > Minor: > > 1. Please be consistent: > * s/exterior BGP/external BGP..or even just EBGP (yes, a nit..but that's how rfc4271 calls EBGP) > * s/best path selection process/Decision Process > * s/IX/IXP > 2. Section 2.2.3. (MULTI_EXIT_DISC Attribute) specifically calls out the MED, but you already said in Section 2.2. (Attribute Transparency) that all optional attributes "SHOULD NOT be updated by the route server…and SHOULD be passed on to other route server clients." Is there anything special about the MED that I'm missing? If not, then you should be able to delete the section. > 3. In Section 2.3.1. (Path Hiding on a Route Server) policy implementation is described in terms of outbound route filtering. The description of the example says that if "AS1's policy prevents AS2's path from being accepted, then AS1 would never receive a path to this prefix". To be consistent with the outbound filtering description, you might want to change that text to something like "AS2's policy prevents AS1 from receiving the path, …" From nobody Mon Feb 8 02:19:48 2016 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 B5AA71ACE5A for ; Mon, 8 Feb 2016 02:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.257 X-Spam-Level: X-Spam-Status: No, score=-98.257 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 IAqZxvFDWjdB for ; Mon, 8 Feb 2016 02:19:45 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 2BF7B1ACE54 for ; Mon, 8 Feb 2016 02:19:45 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: Date: Mon, 8 Feb 2016 05:19:28 -0500 Message-ID: <013201d1625a$31c0e980$9542bc80$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0133_01D16230.48F0FC00" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdFiV6ddedfGvEZZRBexctTrndvi+g== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jgs@bgp.nu Subject: [Idr] IDR interim meeting on 2/8/2016 - Discussion of BGP FLow Specification - 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, 08 Feb 2016 10:19:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0133_01D16230.48F0FC00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0134_01D16230.48F0FC00" ------=_NextPart_001_0134_01D16230.48F0FC00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable IDR Interim meeting =20 Monday, February 8, 2016=20 10:00 am | Eastern Standard Time (New York, GMT-05:00) | 1 hr 30 = mins=20 =20 Webex meeting:=20 https://ietf.webex.com/ietf/j.php?MTID=3Dm358de8f680d54f9b4539cdea4308111= b =20 Meeting number: 644 895 386=20 Meeting password: yang.fun =20 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 644 895 386 =20 Agenda:=20 =20 0) Bash Agenda [10:00 - 10:05 ] 1) BGP Flow Specification Version 2 [10:05 - 10:45] 2 IDR WG drafts [draft-ietf-idr-flow-spec-v6,=20 draft=3Didr-flowspec-l2vpn] and=20 9 proposed drafts suggest additions to BGP Flow=20 specification. On January 11, 2016 we had discussion of the issues of combining these drafts.=20 =20 draft-hares-idr-flow-spec-combo describes:=20 a) issues relating to combination of drafts b) Precedence ordering for new BGP Flow Specification=20 c) Precedence among Routing Functions doing flow Filtering d) Yang models for BGP Flow Specification=20 =20 =20 2) Discussion [10:45-11:30] =20 Questions to discuss:=20 2-1) Should we go toward a BGP Flow Specification version 2 with ordered filters and ordered actions?=20 =20 If so what format:=20 a) BGP Attribute=20 b) BGP NLRI with order + actions=20 c) BGP NLRI + BGP Wide Communities =20 d) Another Format =20 2-2) Shall we Align all the Yang Modules for=20 Filter-Based RIBs (config (aka policy routing), BGP, I2RS)=20 =20 Drafts considered:=20 Flow Specification RFCs: RFC5575, RFC7674 Drafts considered:=20 - draft-hares-idr-flow-spec-combo - draft-ietf-idr-flowspec-v6 - draft-ietf-idr-flowspec-l2vpn - draft-eddy-idr-flowspec-packet-rate - draft-eddy-idr-flowspec-exp - draft-hao-idr-flowspec-nv03 - draft-hao-flowspec-redirect-tunnel=20 - draft-li-idr-flowspec-rpd=20 - draft-liag-idr-bgp-flowspec-label - draft-liang-idr-flowspec-time - draft-litkowski-idr-flowspec-interfaceset - draft-vandevelde-idr-flowspec-path-redirect =20 From: IDR Working Group [mailto:messenger@webex.com]=20 Sent: Monday, February 08, 2016 4:46 AM To: idr-chairs@tools.ietf.org Subject: (Forward to others) WebEx meeting invitation: BGP Flow = Specification =20 You can forward this invitation to others.=20 =20 Hello,=20 IDR Working Group invites you to join this WebEx meeting.=20 =20 =20 =20 BGP Flow Specification=20 Monday, February 8, 2016=20 10:00 am | Eastern Standard Time (New York, GMT-05:00) | 1 hr 30 = mins=20 =20 =20 =20 = Join WebEx meeting=20 =20 Meeting number:=20 644 895 386=20 Meeting password: yang.fun =20 =20 =20 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 644 895 386 Toll-free calling = restrictions =20 =20 =20 = Add this meeting to your calendar. (Cannot add from mobile devices.) =20 =20 =20 Can't join the meeting? Contact = support.=20 =20 =20 =20 IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. =20 ------=_NextPart_001_0134_01D16230.48F0FC00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

IDR Interim meeting=C2=A0

Monday, February 8, 2016

10:00 am=C2=A0 |=C2=A0 Eastern Standard Time (New York, = GMT-05:00)=C2=A0 |=C2=A0 1 hr 30 mins

 

Webex meeting:

https://ietf.webex.com/ietf/j.php?MTID=3Dm358de8f680d54f9b4539cdea4308= 111b

 

Meeting number: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 644 895 386 =

Meeting password:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = yang.fun

 

Join by phone

1-877-668-4493 Call-in toll free number = (US/Canada)

1-650-479-3208 Call-in toll number = (US/Canada)

Access code: 644 895 386

 

Agenda:

=C2=A0

0) Bash Agenda=C2=A0=C2=A0 [10:00 - 10:05 ]

1) BGP Flow Specification Version 2 [10:05 - = 10:45]

=C2=A0=C2=A0=C2=A02 IDR WG drafts [draft-ietf-idr-flow-spec-v6, =

=C2=A0=C2=A0=C2=A0=C2=A0draft=3Didr-flowspec-l2vpn] and =

=C2=A0=C2=A0=C2=A09 proposed drafts suggest additions to BGP Flow =

=C2=A0=C2=A0=C2=A0specification.=C2=A0 On January 11, 2016 we had = discussion

=C2=A0=C2=A0 of the issues of combining these drafts. =

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0draft-hares-idr-flow-spec-combo describes: =

=C2=A0=C2=A0=C2=A0a) issues relating to combination of = drafts

=C2=A0=C2=A0 b) Precedence ordering for new BGP Flow Specification =

=C2=A0=C2=A0=C2=A0c) Precedence among Routing Functions doing flow = Filtering

=C2=A0=C2=A0 d) Yang models for BGP Flow Specification =

=C2=A0

=C2=A0

2) Discussion [10:45-11:30]

 

Questions to discuss:

2-1) =C2=A0Should we go toward a BGP Flow Specification version = 2

with ordered filters and ordered actions?

 

If so what format:

a)      = BGP Attribute

b)      = BGP NLRI with order + actions

c)       = BGP NLRI=C2=A0 + BGP Wide Communities =C2=A0

d)      = Another Format

 

2-2) Shall we Align all the Yang Modules for =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Filter-Based = RIBs (config (aka policy routing), BGP, I2RS)

 

Drafts considered:

Flow Specification RFCs: RFC5575, RFC7674

Drafts considered:

- draft-hares-idr-flow-spec-combo

- draft-ietf-idr-flowspec-v6

- draft-ietf-idr-flowspec-l2vpn

- draft-eddy-idr-flowspec-packet-rate

- draft-eddy-idr-flowspec-exp

- draft-hao-idr-flowspec-nv03

- draft-hao-flowspec-redirect-tunnel

- draft-li-idr-flowspec-rpd

- draft-liag-idr-bgp-flowspec-label

- draft-liang-idr-flowspec-time

- draft-litkowski-idr-flowspec-interfaceset

- draft-vandevelde-idr-flowspec-path-redirect

 

From:= = IDR Working Group [mailto:messenger@webex.com]
Sent: Monday, = February 08, 2016 4:46 AM
To: = idr-chairs@tools.ietf.org
Subject: (Forward to others) WebEx = meeting invitation: BGP Flow = Specification

 

You can forward this invitation to others. =

 

Hello,

IDR Working Group invites you to join this WebEx meeting. =

 

 

 

BGP Flow = Specification =

Monday, February 8, 2016

10:00 am  |  Eastern Standard Time (New York, = GMT-05:00)  |  1 hr 30 mins =

 

 

 

Join = WebEx meeting =

 

Meeting number:

644 895 386

Meeting password:

yang.fun

 

 

 

Join by = phone

1-877-668-4493 Call-in toll free number = (US/Canada)

1-650-479-3208 Call-in toll number = (US/Canada)

Access code: 644 895 386

Toll-free = calling = restrictions

 

 

 

Add this = meeting to your calendar. (Cannot add from mobile = devices.)

 

 

 

Can't join the meeting? Contact support. =

 

 

 

= IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session.

 

------=_NextPart_001_0134_01D16230.48F0FC00-- ------=_NextPart_000_0133_01D16230.48F0FC00 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="WebEx_Meeting.ics" BEGIN:VCALENDAR=0A= PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN=0A= VERSION:2.0=0A= METHOD:REQUEST=0A= BEGIN:VTIMEZONE=0A= TZID:Eastern Time=0A= BEGIN:STANDARD=0A= DTSTART:20141101T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D1SU;BYMONTH=3D11=0A= TZOFFSETFROM:-0400=0A= TZOFFSETTO:-0500=0A= TZNAME:Standard Time=0A= END:STANDARD=0A= BEGIN:DAYLIGHT=0A= DTSTART:20140301T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D2SU;BYMONTH=3D3=0A= TZOFFSETFROM:-0500=0A= TZOFFSETTO:-0400=0A= TZNAME:Daylight Savings Time=0A= END:DAYLIGHT=0A= END:VTIMEZONE=0A= BEGIN:VEVENT=0A= ATTENDEE;CN=3D"IDR Working = Group";ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:MAILTO:idr-chairs@tools.ietf.or= g=0A= ORGANIZER;CN=3D"IDR Working Group":MAILTO:idr-chairs@tools.ietf.org=0A= DTSTART;TZID=3D"Eastern Time":20160208T100000=0A= DTEND;TZID=3D"Eastern Time":20160208T113000=0A= LOCATION:https://ietf.webex.com/ietf=0A= TRANSP:OPAQUE=0A= SEQUENCE:1454924765=0A= UID:98703f6a-b1fd-4428-a437-ddc50197b08a=0A= DTSTAMP:20160208T150000Z=0A= DESCRIPTION:\n\n\nJOIN WEBEX = MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dmc8b8aa7f848fd28489bc9a= 4316bdfa06\nMeeting number: 644 895 386\nMeeting password: = yang.fun\n\n\nJOIN BY PHONE\n1-877-668-4493 Call-in toll free number = (US/Canada) \n1-650-479-3208 Call-in toll number (US/Canada)\nAccess = code: 644 895 386\n\nToll-free dialing restrictions: = \nhttp://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\n\nCan't join = the meeting? Contact support = here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT NOTICE: Please note = that this WebEx service allows audio and other information sent during = the session to be recorded, which may be discoverable in a legal matter. = By joining this session, you automatically consent to such recordings. = If you do not consent to being recorded, discuss your concerns with the = host or do not join the session.\n=0A= X-ALT-DESC;FMTTYPE=3Dtext/html:  
Join WebEx = meeting =
Meeting number: 644 895 = 386
Meeting = password:yang.fun
 
 
Join by = phone 
1-877-668-4493 Call-in toll free = number (US/Canada) 
1-650-479-3208 Call-in toll number = (US/Canada) 
Access code: 644 895 386 
Toll-free calling = restrictions  


 
Can't join the = meeting? Contact support. =  
 
IMPORTANT NOTICE: Please note that this WebEx service = allows audio and other information sent during the session to be = recorded, which may be discoverable in a legal matter. By joining this = session, you automatically consent to such recordings. If you do not = consent to being recorded, discuss your concerns with the host or do not = join the session.=0A= SUMMARY:BGP Flow Specification=0A= PRIORITY:5=0A= CLASS:PUBLIC=0A= BEGIN:VALARM=0A= TRIGGER:-PT5M=0A= ACTION:DISPLAY=0A= DESCRIPTION:Reminder=0A= END:VALARM=0A= END:VEVENT=0A= END:VCALENDAR=0A= ------=_NextPart_000_0133_01D16230.48F0FC00-- From nobody Mon Feb 8 10:33:06 2016 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 CC4B91A8861; Mon, 8 Feb 2016 10:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGEajUXZn0y5; Mon, 8 Feb 2016 10:33:04 -0800 (PST) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) (using TLSv1.2 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8B0D1A01A8; Mon, 8 Feb 2016 10:33:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1454956384; x=1486492384; h=from:to:cc:date:subject:message-id:references: in-reply-to:mime-version; bh=3xNnASwaE2bRHh1BI264tzL82gwRm3uiNw6WFha03YY=; b=sGNjgzP1E04CYAjfRjMwh+oj4mfLRREcwwjZU89MAGklanQSDe0JkfuC kxxqNamOi9AURS4EqsfJMpOIIB45Xae/Lsym8psf2ibWbUSX8BL5ZC7jj yYFS1uNinr+z0WC08yrOArxvPnp0I84oWknvrd51/xXr+WXkl4IvzdEqo A=; IronPort-PHdr: 9a23:0X0AjBJ+oXzdL38z4NmcpTZWNBhigK39O0sv0rFitYgVK/7xwZ3uMQTl6Ol3ixeRBMOAu60C0bqd6f6ocFdDyKjCmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWM5DIfUi/yKRBybrysXNWC0ILth6vopdX6WEZhunmUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO9MxGlldhq5lhf44dqsrtY4q3wD89pozcNLUL37cqIkVvQYSW1+ayFmrPHs4CLeVgKJrlsVSGgN2k5TAwHf4QrSWJvjsm3xse8rnGHQPMHsZbE5RTrk6L1kAle8iSsdHz807G+RjdZ/2vF1uhWk8lZDxIvTfIiWNb42Wr7cZps/DyIVWttQTGpdBYa7c4IMDsIfMPxZvY774VAJqE3tVkGXGOrzx2oQ1TfN1qog3rFkSFme0Q== X-IronPort-Anti-Spam-Filtered: false X-IPAS-Result: A2H2AQAn3rhW/6sueqVYBhkBAQEBDwEBAQEGAQEBAYI0TFJthT6DHbEOAQ2BZiOEE4FXAoEvOBQBAQEBAQEBAQKBB4ItCjg8AQEBAQEBIwI+LQEBAQEDLUwQAgEIDgMEAQEoBzIUCQgBAQQBDQUIh30BFQUJnToBAYcMmHABAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYUhDWEEwEBDRAtCYJ1gQ8FjhuIWgGFS4lfjRiKbINSHgEBQoFMNxmBZkwBhyKBMAEBAQ Received: from omzsmtpi01.vzbi.com ([165.122.46.171]) by omzsmtpe03.verizonbusiness.com with ESMTP; 08 Feb 2016 18:33:02 +0000 From: "Tomotaki, Luis M" X-IronPort-AV: E=Sophos;i="5.22,417,1449532800"; d="scan'208,217";a="596462337" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by omzsmtpi01.vzbi.com with ESMTP; 08 Feb 2016 18:32:58 +0000 Received: from FHDP1LUMXC7V91.us.one.verizon.com ([166.68.240.155]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Mon, 8 Feb 2016 13:32:58 -0500 To: Susan Hares , "idr@ietf.org" Date: Mon, 8 Feb 2016 13:32:57 -0500 Thread-Topic: WG LC missed IPR Statements - 1 WG LC for IPR Thread-Index: AdFgTvATc4xhvDpqSdanGhK2hw1rbACTy0rg Message-ID: <467340A77F13C944919805BFF3B8ACFC30119EA786@FHDP1LUMXC7V91.us.one.verizon.com> References: <002401d16050$5cba52e0$162ef8a0$@ndzh.com> In-Reply-To: <002401d16050$5cba52e0$162ef8a0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_467340A77F13C944919805BFF3B8ACFC30119EA786FHDP1LUMXC7V9_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-sla-exchange@ietf.org" Subject: Re: [Idr] WG LC missed IPR Statements - 1 WG LC for IPR 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, 08 Feb 2016 18:33:06 -0000 --_000_467340A77F13C944919805BFF3B8ACFC30119EA786FHDP1LUMXC7V9_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Susan, No, I am not aware of any IPR related to this document that has not alrea= dy been disclosed. Luis Tomotaki From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, February 05, 2016 2:04 PM To: idr@ietf.org Cc: 'Shitanshu Shah (svshah)'; draft-ietf-idr-sla-exchange@ietf.org; 'Alvar= o Retana (aretana)'; 'John G. Scudder' Subject: WG LC missed IPR Statements - 1 WG LC for IPR After a long review/edit cycle after WG LC, draft-ietf-idr-sla-exchange-07.= txt is ready to go to the IESG. You can see the resulting text at: https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ However, in checking the IPR statements the IDR chairs missed two steps in = the process: Step 1: There was IPR declared in the mail message regarding draft-ietf-i= dr-sla-exchange-03: https://mailarchive.ietf.org/arch/msg/idr/rPvMVsFcM4xO= m1Vz_HNdAM3P250 This IPR is unusual in that the holder of the patent is not one of the auth= ors of the draft as the link shows: https://datatracker.ietf.org/ipr/search/?id=3Ddraft-ietf-idr-sla-exchange&s= ubmit=3Ddraft As a WG Chairs, we must ask again if the WG wants to approve the draft in t= he face of this patent. This begins a 1 Week IPR LC where the WG must send= positive indications they wish to send this document to WG LC. This messa= ge was sent prior to the WG LC (1/19/2015 to 2/5/2015), but no specific men= tion was made. Due to IPR policy, we must get a positive affirmation that = the WG LC wants to adopt this work. All authors to the draft MUST respond = to this IPR call or we cannot forward this to the IESG for publication. Details on these implementations of draft-ietf-idr-sla-exchange are at: https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-sla-exchange%20= implementations Step 2: three of the authors did not declare IPR on-list: Keyur Patel, S= . Bajaj, L. Tomotaki These authors need to declare if they know if additional IPR. Thank you for your patience, Sue Hares and John Scudder --_000_467340A77F13C944919805BFF3B8ACFC30119EA786FHDP1LUMXC7V9_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Susan,

  No, I am not aware of any IPR relat= ed to this document that has not already been disclosed.<= /p>

&nb= sp;

Luis Tomotaki

 <= /span>

From: Susan Hares [mailto:shares= @ndzh.com]
Sent: Friday, February 05, 2016 2:04 PM
To:= idr@ietf.org
Cc: 'Shitanshu Shah (svshah)'; draft-ietf-idr-sla-e= xchange@ietf.org; 'Alvaro Retana (aretana)'; 'John G. Scudder'
Subjec= t: WG LC missed IPR Statements - 1 WG LC for IPR

=

 

= After a long review/edit cycle after WG LC, draft-ietf-idr-sla-exchange-07.= txt is ready to go to the IESG.   You can see the resulting text = at:

 https://datatracker.ietf.org/d= oc/draft-ietf-idr-sla-exchange/

 

However, in checking the IPR statemen= ts the IDR chairs missed two steps in the process:

 

Step 1:  There = was IPR declared in the mail message regarding  draft-ietf-idr-sla-exc= hange-03:  https://mailarchive.ietf.org/arch/msg/idr/rPvMVsFcM4= xOm1Vz_HNdAM3P250

 <= /p>

This IPR is unusual in that the holder of the paten= t is not one of the authors of the draft as the link shows:

=

https://datatracker.ietf= .org/ipr/search/?id=3Ddraft-ietf-idr-sla-exchange&submit=3Ddraft

 

= As a WG Chairs, we must ask again if the WG wants to approve the draft in t= he face of this patent.  This begins a 1 Week IPR LC where the WG must= send positive indications they wish to send this document to WG LC.  = This message was sent prior to the WG LC (1/19/2015 to 2/5/2015), but no sp= ecific mention was made.  Due to IPR policy, we must get a positive af= firmation that the WG LC wants to adopt this work.  All authors to the= draft MUST respond to this IPR call or we cannot forward this to the IESG = for publication.

 

<= p class=3DMsoNormal>Details on these implementations of draft-ietf-idr-sla-= exchange are at:

https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-sla-excha= nge%20implementations

 

 

Step = 2:  three of the authors did not declare IPR on-list:  Keyur Pate= l,  S. Bajaj,  L. Tomotaki

 

These authors need to declare if the= y know if additional IPR.

 

Thank you for your patience,

 

Sue Hares and J= ohn Scudder  

= --_000_467340A77F13C944919805BFF3B8ACFC30119EA786FHDP1LUMXC7V9_-- From nobody Mon Feb 8 11:57:40 2016 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 CE9BB1B326F for ; Mon, 8 Feb 2016 11:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.557 X-Spam-Level: X-Spam-Status: No, score=-93.557 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 FlF1pGZPJe3G for ; Mon, 8 Feb 2016 11:57:37 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 19A6D1B3268 for ; Mon, 8 Feb 2016 11:57:36 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: Date: Mon, 8 Feb 2016 14:57:27 -0500 Message-ID: <004901d162aa$eff41c10$cfdc5430$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01D16281.071F9AB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdFiqr826DKCk5WrTpC/BQegH4aSvA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] 2/8/2016 interim 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, 08 Feb 2016 19:57:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004A_01D16281.071F9AB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Today's interim minutes are online at: https://www.ietf.org/proceedings/interim/2016/02/08/idr/proceedings.html The recording is at: BGP Flow Specification-20160208 1504-1 Monday, February 8, 2016 11:33 am | Eastern Standard Time (New York, GMT-05:00) Duration: 1 hour 27 minutes Security: Description: Streaming recording link: https://ietf.webex.com/ietf/ldr.php?RCID=4635a93af1dcf147727ef28ab79ee2e7 Download recording link: https://ietf.webex.com/ietf/lsr.php?RCID=60f96d781b087b363bbf9138c727aef0 Sue Hares ------=_NextPart_000_004A_01D16281.071F9AB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Today’s interim = minutes are online at:

https://www.ietf.org/proceedings/interim/2016/02/08/idr/proceedi= ngs.html

The recording is at: =

BGP Flow = Specification-20160208 1504-1
Monday, February 8, = 2016
11:33 = am | Eastern Standard Time (New York, GMT-05:00) =

Duration:

1 hour 27 minutes

Security:

Description:

Streaming recording link:

https://ietf.webex.com/ietf/ldr.php?RCID=3D4635a93af1dcf14772= 7ef28ab79ee2e7

Download = recording link:

https://ietf.webex.com/ietf/lsr.php?RCID=3D60f96d781b087b363b= bf9138c727aef0

 

Sue Hares =

 

------=_NextPart_000_004A_01D16281.071F9AB0-- From nobody Mon Feb 8 12:01:59 2016 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 D0AB41B3267; Mon, 8 Feb 2016 12:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENV6IJ3m0Pxj; Mon, 8 Feb 2016 12:01:55 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FBF11B3269; Mon, 8 Feb 2016 12:01:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11907; q=dns/txt; s=iport; t=1454961703; x=1456171303; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3wBdX61ZX79MWNU5um+IyiplOU0i4FMCyDzjO/DwtxQ=; b=A26jLdmEWm4Z1zuinEHWucRpK9ZoDjFDtwzq+hPBsbE7vhTcRQ6UudWY LJP34DllQemA3E/KQSyswTWhvSUk+b2FU9CFXUyxW5rsakToXX2b278GJ XFZVIx+akYeet+1mxpZJol/HBgNX8VAFzxAMN+JXRMNPDjPU9FeC+WgMT M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQCa87hW/40NJK1YBoJuTFJtBohVs?= =?us-ascii?q?Q4BDYFmI4VqAoEvOBQBAQEBAQEBgQqEQQEBAQQtTBACAQgRAwEBASgHMhQJCAI?= =?us-ascii?q?EAQ0FiAYDEg69XwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhhKEN4I3gVwBAQ0WB?= =?us-ascii?q?xMNCYQEBZZ1AYVLiASBW40YimyDUQEeAQFCggMZgUhqAYciNHwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,417,1449532800"; d="scan'208,217";a="234444020" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Feb 2016 20:01:42 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u18K1gcG001206 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Feb 2016 20:01:42 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 8 Feb 2016 15:01:41 -0500 Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1104.009; Mon, 8 Feb 2016 15:01:41 -0500 From: "Keyur Patel (keyupate)" To: "Tomotaki, Luis M" , Susan Hares , "idr@ietf.org" Thread-Topic: WG LC missed IPR Statements - 1 WG LC for IPR Thread-Index: AQHRYquHc4xhvDpqSdanGhK2hw1rbA== Date: Mon, 8 Feb 2016 20:01:41 +0000 Message-ID: References: <002401d16050$5cba52e0$162ef8a0$@ndzh.com> <467340A77F13C944919805BFF3B8ACFC30119EA786@FHDP1LUMXC7V91.us.one.verizon.com> In-Reply-To: <467340A77F13C944919805BFF3B8ACFC30119EA786@FHDP1LUMXC7V91.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.56.85] Content-Type: multipart/alternative; boundary="_000_D2DE340336B7Akeyupateciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-sla-exchange@ietf.org" Subject: Re: [Idr] WG LC missed IPR Statements - 1 WG LC for IPR 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, 08 Feb 2016 20:01:58 -0000 --_000_D2DE340336B7Akeyupateciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sue, +1. I am not aware of any IPR related to this document that has not already= been disclosed. Regards, Keyur From: , Luis M > Date: Monday, February 8, 2016 at 10:32 AM To: Susan Hares >, "idr@ietf.org" > Cc: "Shitanshu Shah (svshah)" >, = "draft-ietf-idr-sla-exchange@ietf.org" >, "Alvaro Retana (aretana)" >, "'John G. Scudder'" > Subject: RE: WG LC missed IPR Statements - 1 WG LC for IPR Susan, No, I am not aware of any IPR related to this document that has not alrea= dy been disclosed. Luis Tomotaki From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, February 05, 2016 2:04 PM To: idr@ietf.org Cc: 'Shitanshu Shah (svshah)'; draft-ietf-idr-sla-exchange@ietf.org; 'Alvaro Retana (aretana)'; 'John G. = Scudder' Subject: WG LC missed IPR Statements - 1 WG LC for IPR After a long review/edit cycle after WG LC, draft-ietf-idr-sla-exchange-07.= txt is ready to go to the IESG. You can see the resulting text at: https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ However, in checking the IPR statements the IDR chairs missed two steps in = the process: Step 1: There was IPR declared in the mail message regarding draft-ietf-i= dr-sla-exchange-03: https://mailarchive.ietf.org/arch/msg/idr/rPvMVsFcM4xO= m1Vz_HNdAM3P250 This IPR is unusual in that the holder of the patent is not one of the auth= ors of the draft as the link shows: https://datatracker.ietf.org/ipr/search/?id=3Ddraft-ietf-idr-sla-exchange&s= ubmit=3Ddraft As a WG Chairs, we must ask again if the WG wants to approve the draft in t= he face of this patent. This begins a 1 Week IPR LC where the WG must send= positive indications they wish to send this document to WG LC. This messa= ge was sent prior to the WG LC (1/19/2015 to 2/5/2015), but no specific men= tion was made. Due to IPR policy, we must get a positive affirmation that = the WG LC wants to adopt this work. All authors to the draft MUST respond = to this IPR call or we cannot forward this to the IESG for publication. Details on these implementations of draft-ietf-idr-sla-exchange are at: https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-sla-exchange%20= implementations Step 2: three of the authors did not declare IPR on-list: Keyur Patel, S= . Bajaj, L. Tomotaki These authors need to declare if they know if additional IPR. Thank you for your patience, Sue Hares and John Scudder --_000_D2DE340336B7Akeyupateciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5662799ED6875E45974A7534D4FCC04B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Sue,

+1. I am not aware of any IPR related to this document that has no= t already been disclosed.

Regards,
Keyur

From: <Tomotaki>, Luis M <= luis.tomotaki@verizon.com&= gt;
Date: Monday, February 8, 2016 at 1= 0:32 AM
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf= .org>
Cc: "Shitanshu Shah (svshah)&q= uot; <svshah@cisco.com>, &quo= t;draft-ietf-idr-sl= a-exchange@ietf.org" <draft-ietf-idr-sla-exchange@ietf.org>, "Alvaro Retana (aretana)" <aretana@cisco.com>, "'John G. Scudder'" <jgs@juniper.net>
Subject: RE: WG LC missed IPR State= ments - 1 WG LC for IPR

Susan,

  = No, I am not aware of any IPR related to this document that has not already= been disclosed.

&n= bsp;

Luis To= motaki

 

From: Susan Hares [ma= ilto:shares@ndzh.com]
Sent: Friday, February 05, 2016 2:04 PM
To: idr@ietf.org
Cc: 'Shitanshu Shah (svshah)'; draft-ietf-idr-sla-exchange@ietf.org; 'Alvaro Retana (aretana)'; 'John = G. Scudder'
Subject: WG LC missed IPR Statements - 1 WG LC for IPR

 

After a long review/edit cycle after WG LC, draft-ie= tf-idr-sla-exchange-07.txt is ready to go to the IESG.   You can = see the resulting text at:

 https://datatracker.ietf.org/doc/draft-ietf-idr= -sla-exchange/

 

However, in checking the IPR statements the IDR chai= rs missed two steps in the process:

 

Step 1:  There was IPR declared in the mail mes= sage regarding  draft-ietf-idr-sla-exchange-03:  https://mailarchive.ietf.org/arch/msg/idr/rPvMVsFcM4xOm1Vz_HNdAM3P25= 0

 

This IPR is unusual in that the holder of the patent= is not one of the authors of the draft as the link shows:

https://datatracker.ie= tf.org/ipr/search/?id=3Ddraft-ietf-idr-sla-exchange&submit=3Ddraft<= o:p>

 

As a WG Chairs, we must ask again if the WG wants to= approve the draft in the face of this patent.  This begins a 1 Week I= PR LC where the WG must send positive indications they wish to send this do= cument to WG LC.  This message was sent prior to the WG LC (1/19/2015 to 2/5/2015), but no specific mention was ma= de.  Due to IPR policy, we must get a positive affirmation that the WG= LC wants to adopt this work.  All authors to the draft MUST respond t= o this IPR call or we cannot forward this to the IESG for publication.

 

Details on these implementations of draft-ietf-idr-s= la-exchange are at:

https://trac.tools.ietf.= org/wg/idr/trac/wiki/draft-ietf-idr-sla-exchange%20implementations=

 

 

Step 2:  three of the authors did not declare I= PR on-list:  Keyur Patel,  S. Bajaj,  L. Tomotaki=

 

These authors need to declare if they know if additi= onal IPR.

 

Thank you for your patience,

 

Sue Hares and John Scudder  

 --_000_D2DE340336B7Akeyupateciscocom_-- From nobody Wed Feb 10 18:33:31 2016 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 C9C071A88E9 for ; Wed, 10 Feb 2016 18:33:20 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 GeRAM3WcVsIx for ; Wed, 10 Feb 2016 18:33:16 -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 285D01A88E8 for ; Wed, 10 Feb 2016 18:33:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CII91709; Thu, 11 Feb 2016 02:33:13 +0000 (GMT) Received: from LHREML705-CAH.china.huawei.com (10.201.5.168) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 11 Feb 2016 02:33:12 +0000 Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 11 Feb 2016 02:33:12 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0235.001; Wed, 10 Feb 2016 18:33:04 -0800 From: Linda Dunbar To: Wesley Eddy , Justin Dailey , "idr@ietf.org" Thread-Topic: questions to draft-eddy-idr-flowspec-exp-00 Thread-Index: AdFkdIg/gEit8njdRkCD1YGUWCwNWg== Date: Thu, 11 Feb 2016 02:33:04 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657DEA4A3@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.2] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657DEA4A3dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56BBF2EA.0032, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 464b97385ec260cbbde7d51550ff869b Archived-At: Subject: [Idr] questions to draft-eddy-idr-flowspec-exp-00 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, 11 Feb 2016 02:33:21 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657DEA4A3dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Wes, et al, I have some questions to your draft-eddy-idr-flowspec-exp-00: 2.1. Packet Rate Action: Is the "packet rate" described here intended for "matching condition"? (sam= e way as the matching types proposed by RFC5575? 2.2. Tunnel Description: - To match a flow with specific outer tunnel and inner TCP or UDP, "logica= l operators (AND, OR, NOR)" should be enough. Why need to specifically stat= e "tunnel"? - The "Offset-Value-Mask" matching is not intended to be propagated = to other peers , is it? - Page 7 last sentence: what does "A" mean in "to address A within a= GRE flow to address Pout ..."? 3. Other discussion: You stated that RFC5575 can be translated easily to ACL. The Matching & Act= ion can. But ACL is local to the node, which are not propagated to peers as= specified by RFC5575. For the Anti-DDoS use case, Controller may only wants to impose the ACL for= a specific node, instead of sending a big wave to all the ASs. Other ASs = may have its own Anti-DDoC controller temporarily steering some suspicious = traffic to its own security scrubbing center. Propagating Anti-DDoS steerin= g policies to other ASs can make the large network oscillate violently (& u= nnecessarily) . To contain the unnecessary complexity, there should be two types of Flow Sp= ec control: - Distributed, i.e. flowSpec coming from (or propagated to) peers. - Centralized, i.e. "Flow Specs" coming from its designated "control= ler". Under the "Centralized" mode, there should be a mode that doesn't propagate= received route policies to peers (i.e. localized policy). Under this "Cen= tralized & no propagating" mode, a lot of tricky issues (like security) goe= s away. Thank you very much. Linda --_000_4A95BA014132FF49AE685FAB4B9F17F657DEA4A3dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Wes, et al,

 

I have some questions to your draft-eddy-idr-flowspe= c-exp-00:

 

2.1. Packet Rate Action:

 

Is the “packet rate= ” described here intended for “matching condition”? (same= way as the matching types proposed by RFC5575?

 

2.2. Tunnel Description:

-  To match a flow w= ith specific outer tunnel and inner TCP or UDP, “logical operators (A= ND, OR, NOR)” should be enough. Why need to specifically state “= ;tunnel”?

 

-       = ; The “Offset-Value-Mask” matching is not intended to be propagated to other peers , is it?

-       = ; Page 7 last sentence: what does “A” mea= n in “to address A within a GRE flow to address Pout …”?

 

 

3. Other discussion:

 

You stated that RFC5575 c= an be translated easily to ACL. The Matching & Action can. But ACL is l= ocal to the node, which are not propagated to peers as specified by RFC5575= .

 

For the Anti-DDoS use cas= e, Controller may only wants to impose the ACL for a specific node, instead= of sending a big wave to all the ASs.  Other ASs may have its own Ant= i-DDoC controller temporarily steering some suspicious traffic to its own security scrubbing center. Propagating Anti-= DDoS steering policies to other ASs can make the large network oscillate vi= olently (& unnecessarily) .

 

To contain the unnecessar= y complexity, there should be two types of Flow Spec control:

-       = ; Distributed, i.e. flowSpec coming from (or propagat= ed to) peers.

-       = ; Centralized, i.e. “Flow Specs” coming f= rom its designated “controller”.

 

Under the “Centrali= zed” mode, there should be a mode that doesn’t propagate receiv= ed route policies to peers (i.e. localized policy).  Under this “= ;Centralized & no propagating” mode, a lot of tricky issues (like security) goes away.

 

Thank you very much.

 

Linda

--_000_4A95BA014132FF49AE685FAB4B9F17F657DEA4A3dfweml701chm_-- From nobody Thu Feb 11 07:18:33 2016 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 D94381B331E; Thu, 11 Feb 2016 07:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJ47OFcMtBhn; Thu, 11 Feb 2016 07:18:29 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1242F1B334A; Thu, 11 Feb 2016 07:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=592; q=dns/txt; s=iport; t=1455203909; x=1456413509; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6Cfwcql29YhQS+SnkfdJqd0AAy8TnNuK7IEeenhnF08=; b=BxmhuH+8Fuf1EAJoGMiZ+hxKzLgYIhDHnz+DPDTb0JP1Nm9Qo+fNfKtV 4ykZXkUFe5drJE0u7b+emREuF2Qr9aNDIb7ROa/Wn+PzNske86pXbk49R 1tMUsTSMV19u61/WjWPB5N3qrioDQtuOBdEMCoQJfJpInc2ev/zhOvrcs 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DnAgD3pLxW/4gNJK1egzqBPwaIVal6h?= =?us-ascii?q?yABDYFnhg0CgTE4FAEBAQEBAQGBCoRCAQEEOj8QAgEINhAyJQIEAQ0FiBrBDgE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBARWGEgGENYhsAQSNJ4VHhAkBjVKBXYRDiFWOP?= =?us-ascii?q?QEeAQFCgimBPGqHV3wBAQE?= X-IronPort-AV: E=Sophos;i="5.22,431,1449532800"; d="scan'208";a="237272587" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Feb 2016 15:18:28 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u1BFIS1J021460 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Feb 2016 15:18:28 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 09:18:27 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Thu, 11 Feb 2016 09:18:27 -0600 From: "Alvaro Retana (aretana)" To: Eric C Rosen , "mpls-chairs@ietf.org" Thread-Topic: [mpls] draft-rosen-idr-rfc3107bis-00 Thread-Index: AQHRTi3mrZ8QLyqAlEOXDyS5JPxiFp8nM0yA Date: Thu, 11 Feb 2016 15:18:27 +0000 Message-ID: References: <5696933E.1080802@juniper.net> In-Reply-To: <5696933E.1080802@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-ads@ietf.org" , "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [Idr] [mpls] draft-rosen-idr-rfc3107bis-00 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, 11 Feb 2016 15:18:31 -0000 On 1/13/16, 1:11 PM, "mpls on behalf of Eric C Rosen" wrote: Hi! >While I put "idr" in the name of the draft, it's not completely >obvious which WG should own this draft (assuming it progresses) Deborah and I had a quick chat about this point and we think that (if it progresses) this document should belong in mpls -- if for no other reason just because RFC3107 was produced there. mpls-chairs: If this document progresses, please make sure that both idr and bess are cc'd on adoption and WGCL. Thanks! Alvaro. From nobody Thu Feb 11 08:07:31 2016 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 08EF21B2E70 for ; Wed, 10 Feb 2016 10:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTFtDina3xPv for ; Wed, 10 Feb 2016 10:35:49 -0800 (PST) Received: from nm2-vm6.bullet.mail.ne1.yahoo.com (nm2-vm6.bullet.mail.ne1.yahoo.com [98.138.91.254]) (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 D549D1B2C53 for ; Wed, 10 Feb 2016 10:35:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1455129347; bh=Cb2VIcHDnmNIyLvSTT09ottHaNm/WeSArvy9doMBlXo=; h=From:Subject:Date:References:In-Reply-To:To:From:Subject; b=P0/tyoAzVExTWqJU0Jp8FDGr2J767lP1qLm+wBVTzJAvxAR+xE1RoMwuF4IuiJ+yh5cpCd5gMxX4vk2sQRnsa/nfsfOOCOHYnacRlI2P5rVbaflytqZWnuxuaICnA0JfpUizVKePM3+vrEDWtoGYYUgZfOKvO3hR72pGHbf7ZhILG/zwIsYnQzo/s/np+cWlMocfwcGOQRnGumAyEySFQ4fy7bwLU/pIl8QGAIEWgKcOiO0Xru4Nwjfja3HeB7AicUx3dNWE5EiH8fnuEAmT/m8CzQbidWF1UeJQ0zWyD+hR034hMGVQu4IDSEfojEmW8xkyTEkGtcurHspvDnmY0Q== Received: from [98.138.100.103] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 10 Feb 2016 18:35:47 -0000 Received: from [98.138.226.130] by tm102.bullet.mail.ne1.yahoo.com with NNFMP; 10 Feb 2016 18:35:47 -0000 Received: from [127.0.0.1] by smtp217.mail.ne1.yahoo.com with NNFMP; 10 Feb 2016 18:35:47 -0000 X-Yahoo-Newman-Id: 742033.56388.bm@smtp217.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: nBbmzqAVM1l1y9PN6AhZkCL9in6M_gNWXr0VbMgJwz3PrMa eCKBpmGwPn1xsoEr0Q_r_DqGn4RLdqNscxeprIwuv1dcglVOXVEkffDJpZrj xoQArDgw7nFmGzSxjvpOsbeiZcK9FC3_6eVo7GriAh3qldq6qVOZIaEY2HVM iPq4ibAw50EmFpRWsCMGsrKD.jwMP5Nv1H0grmniV4pHt8kIyxMK1IWW9qdZ CQJEwcTYSFL5x7Ohl3t6kEJa.5vl7.0CFUTCgvx_BAeYyG_mE6h5NK0KJgTY _A7nbfCW2V1NlH6KpDFtwF_hqhzOX01tr0CfqBqVC5Gcb.vnYhfHrOhhAFFc C_x.xv8HUF7Ve8EAk4Ldo1teuskPrw0yMTjqjYgDkjuS234KFARUC5IFMgHX 5f51dPyNoDfqNuAgB3KJJESHh_AXBXeYUeKhKxFCKjz8MvDfUPgfdSC7Iggu 8Xah4nIfumXLFZZu.HcCruQbD_BhfBT2vBKYcx6KKCu.mpbvZeJ_JyCE1XOv TB0bVQpLcLcR4nY0Y_ns1xiYvS4U4mYxKxGWvLLBOMDzonwGr X-Yahoo-SMTP: 8MazAH.swBBsbEoNPmQXkvU5jv1WMSkhciQ- From: Sandeep Bajaj Content-Type: multipart/alternative; boundary=Apple-Mail-19B6653B-C68A-4D13-B2C5-6939709A539B Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: <853BFC36-1FD5-42D7-97CC-8E2A6BC5DF54@yahoo.com> Date: Wed, 10 Feb 2016 10:35:45 -0800 References: <002401d16050$5cba52e0$162ef8a0$@ndzh.com> <467340A77F13C944919805BFF3B8ACFC30119EA786@FHDP1LUMXC7V91.us.one.verizon.com> In-Reply-To: To: "Shitanshu Shah (svshah)" , shares@ndzh.com, idr@ietf.org, keyurpate@cisco.com, luis.tomotaki@verizon.com, draft-ietf-idr-sla-exchange@ietf.org, jgs@juniper.net, aretana@cisco.com X-Mailer: iPhone Mail (13D15) Archived-At: X-Mailman-Approved-At: Thu, 11 Feb 2016 08:07:31 -0800 Subject: Re: [Idr] WG LC missed IPR Statements - 1 WG LC for IPR 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, 10 Feb 2016 18:35:51 -0000 --Apple-Mail-19B6653B-C68A-4D13-B2C5-6939709A539B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sue I am not aware of any IPR related to this document that has not already been= disclosed. Regs Sandeep Sent from my iPhone > On Feb 10, 2016, at 10:14 AM, Shitanshu Shah (svshah) w= rote: >=20 >=20 >=20 > From: "Keyur Patel (keyupate)" > Date: Monday, February 8, 2016 at 12:01 PM > To: "Tomotaki, Luis M" , Susan Hares , "idr@ietf.org" > Cc: svshah , "draft-ietf-idr-sla-exchange@ietf.org" , "Alvaro Retana (aretana)" , "'John G. Scudder'" > Subject: Re: WG LC missed IPR Statements - 1 WG LC for IPR=20 >=20 > Hi Sue, >=20 > +1. I am not aware of any IPR related to this document that has not alread= y been disclosed. >=20 > Regards, > Keyur >=20 > From: , Luis M > Date: Monday, February 8, 2016 at 10:32 AM > To: Susan Hares , "idr@ietf.org" > Cc: "Shitanshu Shah (svshah)" , "draft-ietf-idr-sla-exch= ange@ietf.org" , "Alvaro Retana (areta= na)" , "'John G. Scudder'" > Subject: RE: WG LC missed IPR Statements - 1 WG LC for IPR=20 >=20 > Susan, > No, I am not aware of any IPR related to this document that has not alre= ady been disclosed. > =20 > Luis Tomotaki > =20 > From: Susan Hares [mailto:shares@ndzh.com]=20 > Sent: Friday, February 05, 2016 2:04 PM > To: idr@ietf.org > Cc: 'Shitanshu Shah (svshah)'; draft-ietf-idr-sla-exchange@ietf.org; 'Alva= ro Retana (aretana)'; 'John G. Scudder' > Subject: WG LC missed IPR Statements - 1 WG LC for IPR > =20 > After a long review/edit cycle after WG LC, draft-ietf-idr-sla-exchange-07= .txt is ready to go to the IESG. You can see the resulting text at: > https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ > =20 > However, in checking the IPR statements the IDR chairs missed two steps in= the process: > =20 > Step 1: There was IPR declared in the mail message regarding draft-ietf-= idr-sla-exchange-03: https://mailarchive.ietf.org/arch/msg/idr/rPvMVsFcM4xO= m1Vz_HNdAM3P250 > =20 > This IPR is unusual in that the holder of the patent is not one of the aut= hors of the draft as the link shows: > https://datatracker.ietf.org/ipr/search/?id=3Ddraft-ietf-idr-sla-exchange&= submit=3Ddraft > =20 > As a WG Chairs, we must ask again if the WG wants to approve the draft in t= he face of this patent. This begins a 1 Week IPR LC where the WG must send p= ositive indications they wish to send this document to WG LC. This message w= as sent prior to the WG LC (1/19/2015 to 2/5/2015), but no specific mention w= as made. Due to IPR policy, we must get a positive affirmation that the WG L= C wants to adopt this work. All authors to the draft MUST respond to this I= PR call or we cannot forward this to the IESG for publication. > =20 > Details on these implementations of draft-ietf-idr-sla-exchange are at: > https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-sla-exchange%2= 0implementations > =20 > =20 > Step 2: three of the authors did not declare IPR on-list: Keyur Patel, S= . Bajaj, L. Tomotaki > =20 > These authors need to declare if they know if additional IPR. > =20 > Thank you for your patience, > =20 > Sue Hares and John Scudder =20 --Apple-Mail-19B6653B-C68A-4D13-B2C5-6939709A539B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Sue

I am not aware of any IPR related to this document that has not already been disclosed.

Regs
Sandeep

Sent from my iPhone

On Feb 10, 2016, at 10:14 AM, Shitanshu Shah (svshah) <svshah@cisco.com> wrote:



From: "Keyur Patel (keyupate)" <keyupate@cisco.com>
Date: Monday, February 8, 2016 at 12:01 PM
To: "Tomotaki, Luis M" <luis.tomotaki@verizon.com>, Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Cc: svshah <svshah@cisco.com>, "draft-ietf-idr-sla-exchange@ietf.org" <draft-ietf-idr-sla-exchange@ietf.org>, "Alvaro Retana (aretana)" <are tans@cisco.com>, "'John G. Scudder'" <jgs@juniper.net>
Subject: Re: WG LC missed IPR Statements - 1 WG LC for IPR

Hi Sue,

+1. I am not aware of any IPR related to this document that has not already been disclosed.

Regards,
Keyur

From: <Tomotaki>, Luis M <luis.tomotaki@verizon.com>
Date: Monday, February 8, 2016 at 10:32 AM
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Cc: "Shitanshu Shah (svshah)" <svshah@cisco.com>, "draft-ietf-idr-sla-exchange@ietf.org" <draft-ietf-idr-sla-exchange@ietf.org>, "Alvaro Retana (aretana)" <aretana@cisco.com>, "'John G. Scudder'" <jgs@juniper.net>
Subject: RE: WG LC missed IPR Statements - 1 WG LC for IPR

Susan,

  No, I am not aware of any IPR related to this document that has not already been disclosed.

 

Luis Tomotaki

 

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Friday, February 05, 2016 2:04 PM
To: idr@ietf.org
Cc: 'Shitanshu Shah (svshah)'; draft-ietf-idr-sla-exchange@ietf.org; 'Alvaro Retana (aretana)'; 'John G. Scudder'
Subject: WG LC missed IPR Statements - 1 WG LC for IPR

 

After a long review/edit cycle after WG LC, draft-ietf-idr-sla-exchange-07.txt is ready to go to the IESG.   You can see the resulting text at:

 https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/

 

However, in checking the IPR statements the IDR chairs missed two steps in the process:

 

Step 1:  There was IPR declared in the mail message regarding  draft-ietf-idr-sla-exchange-03:  https://mailarchive.ietf.org/arch/msg/idr/rPvMVsFcM4xOm1Vz_HNdAM3P250

 

This IPR is unusual in that the holder of the patent is not one of the authors of the draft as the link shows:

https://datatracker.ietf.org/ipr/search/?id=draft-ietf-idr-sla-exchange&submit=draft

 

As a WG Chairs, we must ask again if the WG wants to approve the draft in the face of this patent.  This begins a 1 Week IPR LC where the WG must send positive indications they wish to send this document to WG LC.  This message was sent prior to the WG LC (1/19/2015 to 2/5/2015), but no specific mention was made.  Due to IPR policy, we must get a positive affirmation that the WG LC wants to adopt this work.  All authors to the draft MUST respond to this IPR call or we cannot forward this to the IESG for publication.

 

Details on these implementations of draft-ietf-idr-sla-exchange are at:

https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-sla-exchange%20implementations

 

 

Step 2:  three of the authors did not declare IPR on-list:  Keyur Patel,  S. Bajaj,  L. Tomotaki

 

These authors need to declare if they know if additional IPR.

 

Thank you for your patience,

 

Sue Hares and John Scudder  
--Apple-Mail-19B6653B-C68A-4D13-B2C5-6939709A539B-- From nobody Thu Feb 11 14:44:16 2016 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 CE9E01B3087; Thu, 11 Feb 2016 14:44:07 -0800 (PST) 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 KlTtYqtQi_62; Thu, 11 Feb 2016 14:44:03 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0141.outbound.protection.outlook.com [207.46.100.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 717521B2A28; Thu, 11 Feb 2016 14:44:03 -0800 (PST) Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.35.152] (66.129.241.13) by CY1PR0501MB2155.namprd05.prod.outlook.com (10.164.3.153) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 11 Feb 2016 22:44:00 +0000 To: "Alvaro Retana (aretana)" , "mpls-chairs@ietf.org" References: <5696933E.1080802@juniper.net> From: Eric C Rosen Message-ID: <56BD0EAC.4020700@juniper.net> Date: Thu, 11 Feb 2016 17:43:56 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: CO2PR05CA021.namprd05.prod.outlook.com (10.141.241.149) To CY1PR0501MB2155.namprd05.prod.outlook.com (25.164.3.153) X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2155; 2:M74SHcmnWo/e5j/GT+U/IqLavaKxFwGkhhSHOqraWdjz7+yCMXiaj49dwIeIn7QWz76qD0z+C4CesunqvX8SWUT/0Ggh5Tdu021I5LPoyJ+DIynwYfME+wMWsk2IqeIA5nAEu29LorOIeziF2MXPZA==; 3:cZsyME/AEU4Gxp20oY0DJwiHwjmeseKI4OAYjcKYbikci77ATk7HrxHGDkXvPKxQzZ2Vi3hCRlQ9N6DmL+jv0W29HV58aBoln1NynhdRH5Jx3INUVbKG+omIIDr6EPe2; 25:FDeD7K4XtTMQ2sc5IPPVhlWu0oeTUSf2FOK94gDmo9IDJAwHlkys5e67grq0Yn49V/jcfP42IHehf099JTxCd1h3JJc30K6UjQfnmcOVLUh+WxCGAAKQb0/oYC/4ko5rIZ0pvxF+zV7LJiuBhhoX4VpvkSHlSnbj0lTnEhJ8bjh46yxP+J+4rjP+HCLKV6Hj0+MBZ1W7uAKO/GB3sJwGUuJ1Vvx9tkCqXouWiXzVYQ3miJCXYp2Q04LDLFsmCv0alKzbW9uRZddSbG3PXpueBqbRKPPkPnsEDmComGcyMrY/moYVsQfW/0Z37ifeY5Ou X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB2155; X-MS-Office365-Filtering-Correlation-Id: 93efef9c-4bd5-4b0d-5d53-08d33334d66b X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2155; 20:r9q0ozJv6P17RGJIazrAI4WRG5eCEtvSHgTqxj6O3dUddbmZfzd0Qd/Gybb8yXwCE9H/6pGPxzXrTWkAnocEC+JeKZeCRqe7PD7ya0Cs7eSzJF8mFCnb/GrNsmB95JzIVCUA2MOXPTPk5YBOwi/x30PeIJevq/yyeH+8475Ro15WKz/DCodVFuz6iYExv9jWD72KxqpET2R0z5DKfHZgheBMbQRYH8A64vbK8LCiIknRmrr6ZEXi0hraoiP/ouTczNsKJ5Izz553hJ90RvVuB8JD5DDOFcOP5jBgORupSVn8PG5MQB7tcd1yeccYOI9zfGUDFMhjPv/0fK2sazJfHXNIjRha835pzNAmZnq+KBAz5tix6jtQy6HoszlNnB0eoOHbqEjeQ4sKMVXi4A8Xq+mMWr3mGGSJt7FxMacF3WjvaG5kMJjMTNq1uck9BmNMHMSB7GguO2vkTz4MUmqNnXPxaD9YRHRuy1KTTdelRqG9VlCjX7QaqczWxRM0VFkP; 4:ixr2CVqVmLDZwnsYwwSnFpogNYRU4hRfOQDvwC/S4+csU0zV85CMDCIrMRliK8vhHD2RY8yS0fA9jznzIW17eVl63uwaIp1geLFWaoUBZ3bwMuQUr4bop3qb6ZLcMr8YpfgY01BcDteEFo4rJv6TiD0X6u/ADU6F9LnP4knbPTu2mD4k4WVL2xO+r1hFn8oyRr0/Pc5ny0ZMjJpl9aI69TBbZCH8NCljeLBGTS+9h9X1YlkyC8ZQu+f2fUvI/DToyJySUwRQGasnwhwQgQ67IQOQjizL8/rmQaKRVHTUqb/7PJbgmyxGguzbdCKXSZ5tzeGTnrYQEBkUuW7cnKS4m1Cfj/UPpf5mDhfaHJa/Jdb2yTsE5Gg4vGKhGaPHxFU2pmnH9hORXDzOHbqYKQpJ5N4yAnEoePz6lHeWGgEVR9c= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR0501MB2155; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB2155; X-Forefront-PRVS: 08497C3D99 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(479174004)(24454002)(377454003)(122386002)(230700001)(5008740100001)(19580395003)(19580405001)(40100003)(64126003)(33656002)(230783001)(50466002)(87266999)(586003)(86362001)(87976001)(77096005)(6116002)(3846002)(59896002)(2950100001)(92566002)(83506001)(2501003)(23746002)(42186005)(5004730100002)(50986999)(5001960100002)(1096002)(189998001)(47776003)(54356999)(36756003)(65816999)(66066001)(76176999)(4001350100001)(65806001)(65956001)(2906002)(5001770100001)(4326007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB2155; H:[172.29.35.152]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CY1PR0501MB2155; 23:J5S2vFY1+5O4rHtlqtClz5PkSd2n7JWQ2AS?= =?Windows-1252?Q?7ZXpdZLg5v7hvB1xzExTsdhks3kcQwGFGtILFEI9/VvS8VeFbzeWNZ3y?= =?Windows-1252?Q?OaMMd/4VZ/UULM2nWetYIVzNZrBpel66u+C+ZLa3wC4TJcJIEBsCoKkO?= =?Windows-1252?Q?P5uPv3d27Ujzooyx2XWgmj+dR+IdBb6+9YsAINCRgVcr3JEgYCOe8l3M?= =?Windows-1252?Q?8OZ7F/yz0BMEsbh7vwHnu8ojaApQ5RVtwz6QpQWBq57qTahpUHHGaHYg?= =?Windows-1252?Q?X29nyZYW7ILYQ5s7XWqPUprp1Io/Pz3bybrglZZZe8hDDjXhF72vKvmN?= =?Windows-1252?Q?ictmeQumMcxPdOZag9LGpRmGAAMxu4FwgZwC7jrgSSTw3kWkQPr1NodG?= =?Windows-1252?Q?hVmfWV7C0wvAdN/Y4E5+bg9W4242OMfP/qaOzJR5kpawVMlxE24cRhaY?= =?Windows-1252?Q?317zjPOPp7GUEIbg7MoHlxnTzrti3a6iFH70BGRNPAKNFRFTKfirxekk?= =?Windows-1252?Q?d5Swt8iucFIhueBcWqoeTafcZhd7yAxPsJxCTDc3ooLjqNbgKdOjqIM4?= =?Windows-1252?Q?EmLEgYBlpOodWjioxFIVOitns6+JOUe9xiLqLaxaW4UFe3IaxPlo8ynd?= =?Windows-1252?Q?NkOK1ruN/g6D5HA5WQ6fHoxcVgHEygAsqgPlOw7cpTHQ3/PptCU+VgNE?= =?Windows-1252?Q?pkR8iy0A/K+Lx3NjyRBFA2b/UGUJxMXhIyt6yraQ4RVGYzSRu+3j/fwc?= =?Windows-1252?Q?wSEL/tY9dsK2/fthUW43zSEcXWptQyuqHTOpngWSQfWvhENYeBm5/K+l?= =?Windows-1252?Q?eH0axxYi2kjNWfsQDVAAPheeKfKkRAbyFCoFzeClQiYYEyJ8ho6nx3YG?= =?Windows-1252?Q?C8vZpKbO+l79fLxbpNxdckeaUMI4zzqrfAKMUvB6eI7dQT4KERkl8jGB?= =?Windows-1252?Q?Mu+qNv+YqJgVBrjIboCp4oR9LG6nEywddzBOe8P5fGWs3KdXY8oLxuGr?= =?Windows-1252?Q?RtKY6XxBYxpj4NiAN1/0iGMS9GrnN8U/udCumboSC8wIqO3ALevBhpr/?= =?Windows-1252?Q?R+3ngcqttH2uCKuw7n6mezdFpshUyeHodKgivK7ivbISxDwz/ualUGVe?= =?Windows-1252?Q?egin1ZQGlWp16Ew6/IAfKo8DnyFW7bLyWVuv6BCDZ139YSBecRqlCg+t?= =?Windows-1252?Q?nMjT8Z7by/pVmk3/sWvNR/oaLOO1PyNM3dM/0cmdjqwOofMDTQkLWY+4?= =?Windows-1252?Q?3yWTSa2u++pFsx9mJSxm3ZwxrRFedTzLirpp42pe7yK7NdwfuB0lJGrG?= =?Windows-1252?Q?uJsgg?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2155; 5:Q2aT1JjsVaFKZCNttKPYL9nwWSmsPrpOOOrSzmRmb1Uoot7HxEQTj+McDzPK6EHa21FDD6Zzi58nnb54Qbs3KE0PthGxUUg+zpaUKpfTIUEF6DrzkFwv7Fige46ewGNusaNVrVVBGgP94lphcgoLxQ==; 24:zc7M0rXIN36Pgl7SyY6MLhXZ2DYavNCGZ8S0cdDVuzcXuL89P3cJHspgBUSNyj4S6PQ4eQWrsjeRmiK6jaKYtOwo8na1CaHzdF1h6jBqWig= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Feb 2016 22:44:00.6485 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB2155 Archived-At: Cc: "rtg-ads@ietf.org" , "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [Idr] [mpls] draft-rosen-idr-rfc3107bis-00 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, 11 Feb 2016 22:44:08 -0000 I've reposted the draft as draft-rosen-mpls-rfc3107bis-00. On 2/11/2016 10:18 AM, Alvaro Retana (aretana) wrote: > On 1/13/16, 1:11 PM, "mpls on behalf of Eric C Rosen" > wrote: > > Hi! > >> While I put "idr" in the name of the draft, it's not completely >> obvious which WG should own this draft (assuming it progresses) > Deborah and I had a quick chat about this point and we think that (if it > progresses) this document should belong in mpls -- if for no other reason > just because RFC3107 was produced there. > > mpls-chairs: If this document progresses, please make sure that both idr > and bess are cc'd on adoption and WGCL. > > Thanks! > > Alvaro. > From nobody Thu Feb 11 17:44:35 2016 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 595811A6FBA; Thu, 11 Feb 2016 15:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nL6TDz_2f0ww; Thu, 11 Feb 2016 15:38:26 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56FD91B3C7F; Thu, 11 Feb 2016 15:38:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6146; q=dns/txt; s=iport; t=1455233906; x=1456443506; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=56j+8vLztHIY8UyAk5Lux4jqWX6h7z3uE1/rNEDKk8A=; b=jiRouNYSycAymZ9i/nhEYPXf+NMsQAIowWgop/yeWHklYBV0wlxAc5k+ KIoCdYFopo9dTS9txp13Sut+vLITvpIp38x0Jg7CPnCIIsPC27yrLH/Lu TRajnZGBYIC0AqJ6rFTCUFbCRKjth5c7LfzuWoRRXGApO19h+THU2AMis A=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAgD2Gr1W/5pdJa1egzpSbQaIVbEuD?= =?us-ascii?q?oFnFwqFbAKBNjgUAQEBAQEBAYEKhEEBAQEDAQEBASBLCwULAgEIGCoCAicLJQI?= =?us-ascii?q?EDgUOBod+CA6yM48IAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQQEhhKBbAiCQocyK?= =?us-ascii?q?4EPBZZ3AYJ/gWSIb451jj0BHgFDggIZgUpqh1d8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,433,1449532800"; d="asc'?scan'208";a="236741421" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Feb 2016 23:38:25 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u1BNcPIF004716 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Feb 2016 23:38:25 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 18:38:24 -0500 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Thu, 11 Feb 2016 18:38:24 -0500 From: "Carlos Pignataro (cpignata)" To: Eric C Rosen Thread-Topic: [bess] I-D Action: draft-ietf-idr-tunnel-encaps-01.txt Thread-Index: AQHRQYNgm76iX7yesESh/1GkNtrtOp8oG2EA Date: Thu, 11 Feb 2016 23:38:24 +0000 Message-ID: References: <20151221171512.15817.2209.idtracker@ietfa.amsl.com> <56815342.7030609@juniper.net> In-Reply-To: <56815342.7030609@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.228.25] Content-Type: multipart/signed; boundary="Apple-Mail=_25EBF653-7EAA-4C34-8CC1-C3202866254B"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 11 Feb 2016 17:44:25 -0800 Cc: "idr@ietf.org" , "bess@ietf.org" Subject: Re: [Idr] [bess] I-D Action: draft-ietf-idr-tunnel-encaps-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, 11 Feb 2016 23:38:31 -0000 --Apple-Mail=_25EBF653-7EAA-4C34-8CC1-C3202866254B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Eric, Thanks for sending this out =E2=80=94 I am interested in this document, = and will give it a critical review (in particular the sections you call = out below). In the mean time, however, I wanted to send a few high-level comments = (prepended with =E2=80=9CCMP=E2=80=9D) from scanning through it. I hope = these are useful. 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types This section defines Tunnel Encapsulation sub-TLVs for the following tunnel types: VXLAN ([RFC7348]), VXLAN-GPE ([VXLAN-GPE]), NVGRE ([RFC7637]), GTP ([GTP-U]), MPLS-in-GRE ([RFC2784], [RFC2890], [RFC4023]), L2TPv3 ([RFC3931]), and GRE ([RFC2784], [RFC2890], [RFC4023]). CMP: More comments below, but I am a bit confused about the need to = include MPLS-in-GRE, and the lack of IP-in-IP (Tunnel Type 7) for = example. CMP: A couple of editorial comments as well: For GRE, I think you also = need to cite RFC 7676 (GRE over IPv6) CMP: Also, having this document Obsolete RFC 5512 effectively also = orphans a number of Tunnel types and sub-TLVs. For example, Tunnel Types = values 3-6 from RFC 5566 (IPsec Tunnel Encap) and IPsec Tunnel = Authenticator sub-TLV. I do not know if the answer is to also have that = incorporated (useful parts as you say) and obsoleted. Maybe not, maybe = it does make sense given it is a short doc, which would lead to a = complete self-contained set of Tunnel types. 3.2.4. L2TPv3 =E2=80=A6 Cookie: an optional, variable length (encoded in octets -- 0 to 8 octets) value used by L2TPv3 to check the association of a CMP: The cookie can only take sizes 0, 4, or 8 octets, and not 0..8 3.2.7. MPLS-in-GRE CMP: This seems to be an example and not a separate encapsulation type. = This is GRE Type, with MPLS as protocol sub-TLV. I see that the section = says: While it is not really necessary to have both the GRE and MPLS-in-GRE tunnel types, both are included for reasons of backwards compatibility. CMP: I will also note that having two different ways of doing the same = thing (Tunnel Type 2 and protocol 0x8847 vs. Tunnel Type 11) takes us = away from interop., and that there does not seem to be MPLS-in-GRE = defined in any RFC (so it seems like potentially a good time to = rationalize instead of perpetuate). My $0.02 only. CMP: Should MPLS-over-GRE be an example only? Or otherwise, how do we = interop the two types of =E2=80=9C MPLS-over-GRE=E2=80=9D? Should an = example be also added about MPLS-over-L3TPv3? 3.3.1. IPv4 DS Field CMP: Why not also define this for IPv6? 3.3.2. UDP Destination Port CMP: One additional thought. Obsoleting RFC 5512 also removes the anchor = from RFC 5640 =E2=80=94 that is not a terrible deal in itself, but is = there also an opportunity to generalize the Load-Balancing approach = thereby defined to also include the new encapsulations=E2=80=99 LB, = UDP-based (port as the LB Field), etc? I hope these are clear and useful =E2=80=94 Thanks! =E2=80=94 Carlos. > On Dec 28, 2015, at 10:20 AM, Eric C Rosen wrote: >=20 > The -01 revision of draft-ietf-idr-tunnel-encaps has the following = changes from the -00 revision: >=20 > - By popular request, it has been written in such a way as to obsolete = RFC5512. This means that anything useful in RFC5512 had to be = incorporated into the new draft. I would welcome opinions on whether = this was done correctly. >=20 > - Two new sub-TLVs are specified: "MPLS Label Stack" and = "Prefix-SID". I would welcome opinions on whether these are useful or = not. (I'm pretty sure that the first is useful, the second is more = speculative.) >=20 > - If you are familiar with deployed uses of the Encapsulation Extended = Community, the Color Extended Community, or the Router's MAC Extended = Community, it may be worth checking section 4 to make sure that the = draft does not introduce any problems. >=20 > - I wish more folks would take a critical look at section 8, which is = primarily about the use of VXLAN/NVGRE/VXLAN-GPE together with labeled = address families. >=20 > I would also be interested in hearing if anyone has an opinion on the = utility of using this sort of mechanism to signal IPsec tunnels. Once = RFC 5512 is obsoleted, RFC 5566 ("BGP IPsec Tunnel Encapsulation = Attribute") will need to be revised. It might be possible to generalize = that in such a way as to facilitate the secure interconnection of two = private ASes across the public Internet. Comments on whether RFC 5566 = takes a reasonable approach would be welcome. >=20 >=20 >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess --Apple-Mail=_25EBF653-7EAA-4C34-8CC1-C3202866254B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWvRsmAAoJEIXgpQGOZny95MIP/09bX9/OwVR9f4c0GuE+B3bR lNdtd4oTW054RjrHBdRJyKEpNpsv0iL/Dwnk6L5mrqI+5z3rsubbExWGYb+rOirC 1TZ82kmE/9/cflHVS79djcfHb5lYAAfqDhmNe87fC2DRcr5y86DXyoYGc79ffZmZ 6tI3xwPJmdEl6ix81O56NOL63gXMamtGw0E77gGORCcXTbyRWbdUmrHE25DYwuC+ bG+pME+/U6XYRYUMQsOBEryIByy/B29RSdf+j3Ma+2AYojW42/v2hATxEkurVDla fqTYugCkx9Yrh6b1MbpAYiPz2w1HanRTWYxBHewUiLZJxz6eAdvw/edPe0WOwgSI 9I8vPx9I/0IGLBGg7Xh0o2rILyq8caAYWUpd3l8JDYMJ5+N80zwL1NLwtZi9ecEY BVtADC/ExPaPcue9vn7aUjwqg6TraW2+wmJMyCr1/0bq9pLSbvDdFaVF7wbKZ4+0 Yw6+mYXS+tqZpijPHleZQKnaV+hfVW2H/8B+Lzt1JtdUJEtNa020NQ3YzcRBeCo0 Vzjbe9+KFuuxEJmOw/qxgHS90yAmtmjorzdH6H2ZuE/1n09ScEUygLIF1SqCFwmF e+f5NGnT8vpPTK2L30uTnVLKy9YR0W+NWuVLN7WAQZR/yByfBmlrJEI3xnSCZbvi jPXCibaTA/UhfWnG656O =rR1X -----END PGP SIGNATURE----- --Apple-Mail=_25EBF653-7EAA-4C34-8CC1-C3202866254B-- From nobody Mon Feb 15 02:10:02 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E82C01B30EF; Mon, 15 Feb 2016 02:09:58 -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: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160215100958.14992.61434.idtracker@ietfa.amsl.com> Date: Mon, 15 Feb 2016 02:09:58 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-sla-exchange-impl-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: Mon, 15 Feb 2016 10:09:59 -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 of the IETF. Title : Inter-domain SLA Exchange Implementation Report-01 Authors : Shitanshu Shah Keyur Patel Filename : draft-ietf-idr-sla-exchange-impl-01.txt Pages : 5 Date : 2016-02-15 Abstract: This document is a report of implementations based on [IDR-SLA]. [IDR-SLA] introduces a new BGP attribute to exchange QoS SLA parameters between BGP peers. Current status of the implementation report covers Cisco implementation on 2 different OS, ExaBGP implementation and inter-operability results between them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange-impl/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-sla-exchange-impl-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-sla-exchange-impl-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 Mon Feb 15 09:22:44 2016 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 10F0B1A8A4C; Mon, 15 Feb 2016 09:22:41 -0800 (PST) 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 z9y_GJnRHH8x; Mon, 15 Feb 2016 09:22:34 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0756.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:756]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8B71A89D3; Mon, 15 Feb 2016 09:22:33 -0800 (PST) Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.34.136] (66.129.241.11) by CY1PR0501MB2154.namprd05.prod.outlook.com (10.164.3.152) with Microsoft SMTP Server (TLS) id 15.1.409.15; Mon, 15 Feb 2016 17:22:10 +0000 To: "Carlos Pignataro (cpignata)" References: <20151221171512.15817.2209.idtracker@ietfa.amsl.com> <56815342.7030609@juniper.net> From: Eric C Rosen Message-ID: <56C2093D.7080800@juniper.net> Date: Mon, 15 Feb 2016 12:22:05 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BY2PR13CA0036.namprd13.prod.outlook.com (25.162.223.46) To CY1PR0501MB2154.namprd05.prod.outlook.com (25.164.3.152) X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2154; 2:EKO5RYP6SSQfIC39WuY9c+4/mGwUe+LdwBCb28HFQX14YDTJbibr9m3mnoBXFLiVyb9nPttUEhUJBo8PP2IWHbv9KiTQDkL8GBOmJgQntY7a1T1MtH2n0pfAvE5/Q6sri8WIViMPwaOAOdBTtzas7g==; 3:kY1nddgYJQFZN4GzsV73gh6W2TUhgRlE/cQ4J6tBR/O8ZKI87OR4C7Z1/XFrZR9r2YQIeB9166IhwmJgj8RNmcOxX8VdmgzxqWC6qXRBYZCaw1QxeKKnwyYBC6Dxg8Db; 25:WIzdP+c5xNm6i8qQhONqelVYJlY5biCuZhPsEblDlt6pYzQWdyS3BBG5rviKYI0t/HS8hxawWECjS6xadwRQnPYz+eZus2oii7ubXUaoPfHkHxmrd6VL1E6gs0Q6GIVzUWZFpAPXJzdkp7w+JC0IMOyLO+u6aVv+3ALl4qyms+Vi2zkUE2/OKTgJgnbt39FdHBYjEb/SEHAbqUwHIMqFRg9dFaOgUP22magLY4F6+hNCIgYyd41AMpM9c+dCc/LjfNtti/d6Sg+Ocw3UaKtBHHD9uSjLX71OgcbtqtOrG0Hb70xRoTaGyS4e+Wxygw5S X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB2154; X-MS-Office365-Filtering-Correlation-Id: cb85da8b-a160-477b-fe15-08d3362c8a69 X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2154; 20:DbP7Jt5IxKLpXctHjQyfqcABcV/HO4o9lnmPTj361rFUlrJMKAFzpjO9jN083fdIDf62UadIgNF00bi4nlSkbq6s2qsYGRaqjnzZhG0T2XUgQWUzAFP1apgxqRUOPaRSEw1LtzFoluJEmrpMG4tPnFDnmRObdMIQq16onCKAM9Br/kSmfvY6jOY63YmTWI5hRZP82bUQAuafsKTY23eNhEDTuX3f2Cv5pXMkYl9egUYYIhaqJABg2joITur4oUmKDHM76Z61Qau+oyJGsvr/x2osDnZLbMhze7B1lwyCSOc19lVOW8TE3AsL/H3anFEGFSOsQpGVeEm0ItGLSyipgFD64AtZR04UEreTsk2bhgI77YGzdgh6aTbJ11hdX2iUJ2y0TBBMJIs0+tDmUUhYaD1you+np0c+mJJFaNoxIgmRwGSHXsScx8bqALbShBaXqhGly/NsHxnm+E0cL149NWLITVZyzjDhiUbicinueBziEeqls5i2tjmRRQu9aFfe; 4:y/QuF70OwL7XrrRes9NvYQLzZC9Ft6BmFMlZSKLoj3LQxo493PHAcc5qwV70SgRzBlMUzDdO73Vct7xmgdwKucnarFlqhd36W4SnTv6Jc2lkaBtDWfgPZM50FsgDy6VOpeWgZgLRACwHjteYoJ0LZlUuuT8MuXKN2CdVe96xVe7lVBcV0DmelH4xbfs/Emamxxn/ALkvANOsSKZwwn2JQs2I6xPFR5KkSeHDYcT6K2J12j8fSEBZEIO7lxXWbAVLSfKRecrXq69Zt+8xA0iLpxUOLUfLyw+E5ffoUI2NxIQD0AfiOcr2QS9/o3SXuTjdhLA7U1JkS5asat7HnFPHemA7P1QG0NF7VUNV57PvEYaVB3ExGGMvJn0bVnRqk06X X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR0501MB2154; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB2154; X-Forefront-PRVS: 08534B37A7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(52604005)(479174004)(377454003)(24454002)(189998001)(36756003)(5890100001)(42186005)(80316001)(4001350100001)(83506001)(110136002)(86362001)(50466002)(5001960100002)(23676002)(5004730100002)(2870700001)(50986999)(65816999)(87976001)(77096005)(1096002)(33656002)(122386002)(5008740100001)(87266999)(54356999)(76176999)(65806001)(586003)(92566002)(2906002)(40100003)(6116002)(4326007)(230783001)(66066001)(65956001)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB2154; H:[172.29.34.136]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA1MDFNQjIxNTQ7MjM6blh0dVhsQWhIdzY2aVJoMVlYdzEzaXRK?= =?utf-8?B?bTV6WjVPNmc4WmR6YzJKc2Rtc2VUK3JPQk1Fc011K01Kd1ZwRTEvN3V1eGU5?= =?utf-8?B?T3RjcDRBQWtLVFEwaU1yTzg0MElYcUlEbGJjVGQ5NkI2Sit5Vkxkb2RMV3VY?= =?utf-8?B?Z3FkN09VQjdhRVVjcVRaU0ZFaElFbTVxZ0VuY01uM1UvaGV2YVRkVmswL0s5?= =?utf-8?B?b2xPZDdReE04Y202RG0zNFVNaWppejVwSHRWZnZra01yOU9lazF5SUtFNjM1?= =?utf-8?B?MlFwVVFYWEttb1phTUg3N2x5a2RPTHBmekFtb1Q0aDMzaHVMVXlLaXFDMEtq?= =?utf-8?B?VUt2UVJvOTF3VFlNSDlQM1RmVm5od2MvcmJac1Z2VW1PZkxBRE14ZGovVnAv?= =?utf-8?B?aGRvVjQ0b0pRVUxsajRTdmZuZTFseS9JM3lZdzM4Nit4UXhNQ3dtdXVUSmtT?= =?utf-8?B?cEt0REVkOFpMSWRVSmRZWE1Sd1hyZklyekJOSXBZK0hpZy9rT1Fka2VxN2R5?= =?utf-8?B?Ry85RWdZdlVOQ1prRFAyUG53dTNRd3N4OTlpQ1RQZzV3SjdGU2RpR2UvL0Uv?= =?utf-8?B?WnZWTUNGNXpuRmh4MjVqcEczcy9jQmxRUHp4VE5qVUJnTEVZTFJmeTB1aEpF?= =?utf-8?B?NDROOUU5emVzUVp3b1hUTmJ2K2xWK21uU1FLT1Z1R3llOWxXejdsdUJyWXM4?= =?utf-8?B?d3NRUkJ6ZC9GWmVqM2pUU0JrbGxJNk9kT2g0TXRjeFlHVWQ1bGpNWng1aC90?= =?utf-8?B?QzhZMUFvS3BHTEM2a2sycEZVMGZrTTZKVkdBUi9SV0dOVUM2OTlEOWVRa3lz?= =?utf-8?B?NWwreHFySDNtTFgwWElSUWxXejlXeVFDcmppSW9zUVYwc2JQVFNmZmZ2dEVi?= =?utf-8?B?dG5KRUlFK2hUdzlKQ2pEalR4WnFINUxscVNucDA5QVpLL25EclF3bDVLa2t6?= =?utf-8?B?Njl3SkdjYit3SlgvaXl3Zno3dW1EMklaRnFvc3o2Q2xxclV6OE8rcVNZQ3do?= =?utf-8?B?cjVSSHhPa3BxYzgxWnVVNHBjOHlhdUtNSnhxenlJZW4zRHltZDcxS0hwZkY5?= =?utf-8?B?OEFnWFZQUGx0dE5TaVFXc0FUYXB5b1JQamdxQk9rcmxPOFk2Q0ZUeGdkLzl5?= =?utf-8?B?QXRiK2cwK0dWaUkvbG9QRUJJTVRYY1ZsSzB0ckNFa1JuKzlKYy9WUXlZZ1Qy?= =?utf-8?B?RlA0Mm9QTTNGRkJ0MXRTaEpMOTdYeHVDSDVabmxabDRkQmxjRDRGRnBXWEox?= =?utf-8?B?YzRjZUVrWFNCWEhFSDFtQzVmSDZRbExlZWlPOW0yN3VvVWZTL0JiU0oxT3hE?= =?utf-8?B?OE9FTFluQ1I3ZXJQdjNmWnFRbi9BMGFHRVhhRUFmcHhlbXNjTHBJajFHZzJT?= =?utf-8?B?UnB0MHF5c2RteU1RM2lHbnlPaDl4RHI0NzFpTDA1eXZaV0o0UFVhcnBQNW5j?= =?utf-8?B?Y1BxMEl6OUZRK3VpVmFnbHhlQllkdC94dmZ6Q0dvZzh3dmk5Q0g4c2RCaWF4?= =?utf-8?B?eU5ObjJYRHVDMGljbzBoYmlqSE5GdEhVZTZFOEpPR1lGd1U3dDAwS3JDUENB?= =?utf-8?Q?gzt?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2154; 5:kxZTnC9k9rV042O0KAzq0npmxVfjWYA9621pYnJKxduYWySUtsSHUcDau5cUBvvxtI7d6im0Kqs86pqA7hKofExMtJHgtgDJTvhPsNZzLyMGVny5YakwvkAPluzDD0ZwhQ+bu9/b2mArlDOylhZSYg==; 24:3b0W4/qXrmcdhf70WD1Ex+/1BHKrOJW4a+UI5i+xZlmAxSw29dsvWQQ+fJhKeoy8VpDwSRZyg60m9YHPMF1Wl860vSZ2hPAzaiVDp3fgXHU= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Feb 2016 17:22:10.8815 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB2154 Archived-At: Cc: "idr@ietf.org" , "bess@ietf.org" Subject: Re: [Idr] [bess] I-D Action: draft-ietf-idr-tunnel-encaps-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: Mon, 15 Feb 2016 17:22:41 -0000 On 2/11/2016 6:38 PM, Carlos Pignataro (cpignata) wrote: > Hi, Eric, > > Thanks for sending this out — I am interested in this document, and will give it a critical review (in particular the sections you call out below). Thanks! > > In the mean time, however, I wanted to send a few high-level comments (prepended with “CMPâ€) from scanning through it. I hope these are useful. > > 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types > > This section defines Tunnel Encapsulation sub-TLVs for the following > tunnel types: VXLAN ([RFC7348]), VXLAN-GPE ([VXLAN-GPE]), NVGRE > ([RFC7637]), GTP ([GTP-U]), MPLS-in-GRE ([RFC2784], [RFC2890], > [RFC4023]), L2TPv3 ([RFC3931]), and GRE ([RFC2784], [RFC2890], > [RFC4023]). > > > CMP: More comments below, but I am a bit confused about the need to include MPLS-in-GRE, and the lack of IP-in-IP (Tunnel Type 7) for example. MPLS-in-GRE is included in section 3.2 because there is already a tunnel type codepoint allocated for it, and if that tunnel type is used, an encapsulation sub-TLV is needed in order to signal the GRE key. One can argue that there is no need for the MPLS-in-GRE tunnel type, since everything you can do with it could be done instead with the GRE tunnel type. But unless and until we decide to deprecate the MPLS-in-GRE tunnel type, it needs to be included. In theory, I would love to see the MPLS-in-GRE tunnel type deprecated, but I worry that that might introduce a backwards compatibility problem. This is certainly something that can be discussed by the WG. IP-in-IP is not mentioned in section 3.2 because, although there is a tunnel type codepoint allocated for it, no one has ever defined an encapsulation sub-TLV for it. Also, if it is necessary to signal values for the fields of the outer iP header, it might make more sense to use an "outer encapsulation sub-TLV" (section 3.3). Do you have an opinion about this? > > CMP: A couple of editorial comments as well: For GRE, I think you also need to cite RFC 7676 (GRE over IPv6) Sure. > > CMP: Also, having this document Obsolete RFC 5512 effectively also orphans a number of Tunnel types and sub-TLVs. For example, Tunnel Types values 3-6 from RFC 5566 (IPsec Tunnel Encap) and IPsec Tunnel Authenticator sub-TLV. I do not know if the answer is to also have that incorporated (useful parts as you say) and obsoleted. Maybe not, maybe it does make sense given it is a short doc, which would lead to a complete self-contained set of Tunnel types. I think RFC 5566 will have to be obsoleted and replaced. I've been thinking about that, but I'm still not sure how much of 5566 should be moved into the tunnel-encaps draft and how much should be in a separate draft. There are some non-obvious issues to consider. For example, 5566 really is just intended to facilitate iPsec Security Associations between BGP Next Hops, but with the tunnel encapsulation attribute we could presumably set up Security Associations from ingress to egress. > > 3.2.4. L2TPv3 > … > Cookie: an optional, variable length (encoded in octets -- 0 to 8 > octets) value used by L2TPv3 to check the association of a > > CMP: The cookie can only take sizes 0, 4, or 8 octets, and not 0..8 Do you have a reference for that? Section 4.1 of RFC 3931 seems to say only that the field is variable length with a maximum size of 64 bits. > > 3.2.7. MPLS-in-GRE > > CMP: This seems to be an example and not a separate encapsulation type. This is GRE Type, with MPLS as protocol sub-TLV. I see that the section says: > > While it is not really necessary to have both the GRE and MPLS-in-GRE > tunnel types, both are included for reasons of backwards > compatibility. > > CMP: I will also note that having two different ways of doing the same thing (Tunnel Type 2 and protocol 0x8847 vs. Tunnel Type 11) takes us away from interop., and that there does not seem to be MPLS-in-GRE defined in any RFC (so it seems like potentially a good time to rationalize instead of perpetuate). My $0.02 only. Tunnel type 11 is used by draft-ietf-bess-evpn-overlay. > > CMP: Should MPLS-over-GRE be an example only? Or otherwise, how do we interop the two types of “ MPLS-over-GREâ€? Well, the two ways of doing the same thing are explicitly defined to be equivalent, so I don't think there is an interop issue, the issue is more of "can we get rid of the MPLS-in-GRE type without causing a backwards compatibility problem". > Should an example be also added about MPLS-over-L3TPv3? Surely no one will ever propose MPLS-over-L2TPv3 again! > > 3.3.1. IPv4 DS Field > > CMP: Why not also define this for IPv6? There are a lot of possible Outer Encapsulation sub-TLVs that could be created, I only included a couple of examples that seemed like they might be useful. If you have some sub-TLVs to suggest for the case where the outer encapsulation is IPv6, please suggest some text. (Some IPv6-specific text will probably make it easier to get the draft past the IESG ;-)) > > 3.3.2. UDP Destination Port > > CMP: One additional thought. Obsoleting RFC 5512 also removes the anchor from RFC 5640 — that is not a terrible deal in itself, but is there also an opportunity to generalize the Load-Balancing approach thereby defined to also include the new encapsulations’ LB, UDP-based (port as the LB Field), etc? I wasn't aware of RFC 5640. I don't think there's anything in RFC 5640 that requires the Encapsulation-SAFI. So at a minimum, I think we can get by with saying that the tunnel-encaps draft updates RFC 5640, and that the LB Block sub-TLV can be included in the a tunnel TLV of a tunnel encapsulation attribute that is attached to an update of any AFI/SAFI. If you think it is worthwhile to generalize the load balancing approach of RFC 5640, perhaps the best approach would be to do a 5640bis. > > I hope these are clear and useful — Thanks! > Looking forward to any additional comments you might have! From gunter.van_de_velde@nokia.com Tue Feb 16 05:59:11 2016 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 632D31B2CC2 for ; Tue, 16 Feb 2016 05:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 axVjLs2LbDlM for ; Tue, 16 Feb 2016 05:59:04 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (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 6EE721B29F7 for ; Tue, 16 Feb 2016 05:59:04 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id A47BAC8D04F37 for ; Tue, 16 Feb 2016 13:58:59 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1GDx1XG007772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 16 Feb 2016 13:59:02 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 u1GDx10F027412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 16 Feb 2016 14:59:01 +0100 Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.137]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 16 Feb 2016 14:59:01 +0100 From: "Van De Velde, Gunter (Nokia - BE)" To: "idr@ietf.org" Thread-Topic: [Feedback request] Are there implementations of draft-ietf-idr-flowspec-redirect-ip-02 out there? Thread-Index: AQHRaMIwf2HTDCcwb0qQXOqjdaaCNQ== Date: Tue, 16 Feb 2016 13:59:01 +0000 Message-ID: <09D3C0C6-E1B5-496B-82C9-93D7A745E196@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_09D3C0C6E1B5496B82C993D7A745E196alcatellucentcom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 16 Feb 2016 08:47:07 -0800 Subject: [Idr] [Feedback request] Are there implementations of draft-ietf-idr-flowspec-redirect-ip-02 out there? 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, 16 Feb 2016 14:00:57 -0000 --_000_09D3C0C6E1B5496B82C993D7A745E196alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkhpIEFsbCwNCg0KSSBhbHJlYWR5IGRpZCBhIHByZS1jaGVjayB3aXRoIHRoZSBjby1hdXRo b3JzIG9mIHRoaXMgZHJhZnQgYWxyZWFkeSwgYW5kIGFtIG5vdyByZWFjaGluZyBvdXQgdG8gdGhl IElEUiBXRy4NCg0KSW4gdGhlIGJhY2tlbmQgcHJvY2VzcyBvZiBoZWxwaW5nIFdpbS9BZGFtIHJl Z2FyZGluZyBkcmFmdC1pZXRmLWlkci1mbG93c3BlYy1yZWRpcmVjdC1pcCB0byByZXF1ZXN0IElB TkEgYW4gZXh0ZW5kZWQgY29tbXVuaXR5IHN1Yi10eXBlIHRvIGZ1cnRoZXIgdXBkYXRlIHRoZSBk cmFmdCBpIHdhcyB3b25kZXJpbmcgaWYgYW55IGltcGxlbWVudGVkIGRyYWZ0LWlldGYtaWRyLWZs b3dzcGVjLXJlZGlyZWN0LWlwLTAxIG9yIGRyYWZ0LWlldGYtaWRyLWZsb3dzcGVjLXJlZGlyZWN0 LWlwLTAyID8gSWYgeWVzLCB3aGF0IGlzIHRoZSBzdWItdHlwZSB5b3UgdXNlZD8NCg0KSSB1bmRl cnN0b29kIHRoYXQgc29tZSBwb3RlbnRpYWxseSBpbXBsZW1lbnRlZCBlYXJsaWVyIGRyYWZ0LXNp bXBzb24taWRyLWZsb3dzcGVjLXJlZGlyZWN0LTAyICwgYnV0IHRoYXQgb25lIGlzIGVmZmVjdGl2 ZWx5IGJlaW5nIGRlcHJlY2F0ZWQuDQoNCk1hbnkgdGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlcywN CkcvDQoNCg0K --_000_09D3C0C6E1B5496B82C993D7A745E196alcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: <9B7A01EB24B131489D75358F428838C8@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+ PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4g aWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFr OiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBBbGwsPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBhbHJl YWR5IGRpZCBhIHByZS1jaGVjayB3aXRoIHRoZSBjby1hdXRob3JzIG9mIHRoaXMgZHJhZnQgYWxy ZWFkeSwgYW5kIGFtIG5vdyByZWFjaGluZyBvdXQgdG8gdGhlIElEUiBXRy4mbmJzcDs8L2Rpdj4N CjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29y ZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGlu ZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6 ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PkluIHRoZSBiYWNrZW5kIHByb2Nlc3Mgb2YgaGVscGluZyBXaW0vQWRhbSBy ZWdhcmRpbmcgZHJhZnQtaWV0Zi1pZHItZmxvd3NwZWMtcmVkaXJlY3QtaXAgdG8gcmVxdWVzdCBJ QU5BIGFuIGV4dGVuZGVkIGNvbW11bml0eSBzdWItdHlwZSB0byBmdXJ0aGVyIHVwZGF0ZSB0aGUg ZHJhZnQgaSB3YXMgd29uZGVyaW5nIGlmIGFueSBpbXBsZW1lbnRlZCZuYnNwO2RyYWZ0LWlldGYt aWRyLWZsb3dzcGVjLXJlZGlyZWN0LWlwLTAxIG9yJm5ic3A7ZHJhZnQtaWV0Zi1pZHItZmxvd3Nw ZWMtcmVkaXJlY3QtaXAtMDINCiA/IElmIHllcywgd2hhdCBpcyB0aGUgc3ViLXR5cGUgeW91IHVz ZWQ/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIHVuZGVyc3Rvb2QgdGhhdCBzb21l IHBvdGVudGlhbGx5IGltcGxlbWVudGVkIGVhcmxpZXIgZHJhZnQtc2ltcHNvbi1pZHItZmxvd3Nw ZWMtcmVkaXJlY3QtMDIgLCBidXQgdGhhdCBvbmUgaXMgZWZmZWN0aXZlbHkgYmVpbmcgZGVwcmVj YXRlZC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk1hbnkgdGhhbmtzIGZvciB5b3Vy IHJlc3BvbnNlcyw8L2Rpdj4NCjxkaXY+Ry88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48bGluayByZWw9IkZpbGUtTGlz dCIgaHJlZj0iZmlsZTovL2xvY2FsaG9zdC9Vc2Vycy9ndmFuZGV2ZS9MaWJyYXJ5L0dyb3VwJTIw Q29udGFpbmVycy9VQkY4VDM0Nkc5Lk9mZmljZS9tc29jbGlwMS8wMS9jbGlwX2ZpbGVsaXN0Lnht bCI+PGxpbmsgcmVsPSJ0aGVtZURhdGEiIGhyZWY9ImZpbGU6Ly9sb2NhbGhvc3QvVXNlcnMvZ3Zh bmRldmUvTGlicmFyeS9Hcm91cCUyMENvbnRhaW5lcnMvVUJGOFQzNDZHOS5PZmZpY2UvbXNvY2xp cDEvMDEvY2xpcF90aGVtZWRhdGEudGhteCI+PHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5p dGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAx MSA2IDQgMiAyIDIgMiAyIDQ7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZv bnQtZmFtaWx5OmF1dG87DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2ln bmF0dXJlOi01MzY4NTk5MDUgLTEwNzM3MTEwMzcgOSAwIDUxMSAwO30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDsNCgltc28tZm9udC1jaGFyc2V0OjE7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6cm9tYW47 DQoJbXNvLWZvbnQtZm9ybWF0Om90aGVyOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1z by1mb250LXNpZ25hdHVyZTowIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7DQoJbXNvLWZvbnQtY2hh cnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OmF1dG87DQoJbXNvLWZvbnQtcGl0Y2g6 dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MzY4NzAxNDUgMTA3Mzc4NjExMSAxIDAg NDE1IDA7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLXFm b3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6 Q2FsaWJyaTsNCgltc28tYXNjaWktdGhlbWUtZm9udDptaW5vci1sYXRpbjsNCgltc28tZmFyZWFz dC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6bWlub3ItbGF0 aW47DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWhhbnNpLXRoZW1lLWZv bnQ6bWlub3ItbGF0aW47DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 DQoJbXNvLWJpZGktdGhlbWUtZm9udDptaW5vci1iaWRpO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1kZWZhdWx0LXByb3BzOnllczsNCglmb250 LWZhbWlseTpDYWxpYnJpOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1h c2NpaS10aGVtZS1mb250Om1pbm9yLWxhdGluOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJbXNvLWZhcmVhc3QtdGhlbWUtZm9udDptaW5vci1sYXRpbjsNCgltc28taGFuc2kt Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktdGhlbWUtZm9udDptaW5vci1sYXRpbjsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS10aGVt ZS1mb250Om1pbm9yLWJpZGk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NTk1LjBwdCA4 NDIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7DQoJbXNvLWhlYWRl ci1tYXJnaW46MzUuNHB0Ow0KCW1zby1mb290ZXItbWFyZ2luOjM1LjRwdDsNCgltc28tcGFwZXIt c291cmNlOjA7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT4N Cjwvc3R5bGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_09D3C0C6E1B5496B82C993D7A745E196alcatellucentcom_-- From nobody Tue Feb 16 14:27:46 2016 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 EF40E1A8951; Tue, 16 Feb 2016 13:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.908 X-Spam-Level: X-Spam-Status: No, score=-101.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-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 aTLG8iR_6C3n; Tue, 16 Feb 2016 13:57:01 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715A21A88B3; Tue, 16 Feb 2016 13:57:01 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A678C180014; Tue, 16 Feb 2016 13:56:50 -0800 (PST) To: wes@mti-systems.com, roque@cisco.com, nsheth@juniper.net, raszuk@cisco.com, bgreene@juniper.net, jmauch@us.ntt.net, danny@arbor.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160216215650.A678C180014@rfc-editor.org> Date: Tue, 16 Feb 2016 13:56:50 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 16 Feb 2016 14:27:44 -0800 Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, idr@ietf.org Subject: [Idr] [Errata Held for Document Update] RFC5575 (4482) 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, 16 Feb 2016 21:57:03 -0000 The following errata report has been held for document update for RFC5575, "Dissemination of Flow Specification Rules". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5575&eid=4482 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Wesley Eddy Date Reported: 2015-09-25 Held by: Alvaro Retana (IESG) Section: 4 (page 11) Original Text ------------- An example of a flow specification encoding for: "all packets to 10.0.1/24 from 192/8 and port {range [137, 139] or 8080}". +------------------+----------+-------------------------+ | destination | source | port | +------------------+----------+-------------------------+ | 0x01 18 0a 01 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 | +------------------+----------+-------------------------+ Corrected Text -------------- An example of a flow specification encoding for: "all packets to 10.1.1/24 from 192/8 and port {range [137, 139] or 8080}". +------------------+----------+-------------------------+ | destination | source | port | +------------------+----------+-------------------------+ | 0x01 18 0a 01 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 | +------------------+----------+-------------------------+ OR: An example of a flow specification encoding for: "all packets to 10.0.1/24 from 192/8 and port {range [137, 139] or 8080}". +------------------+----------+-------------------------+ | destination | source | port | +------------------+----------+-------------------------+ | 0x01 18 0a 00 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 | +------------------+----------+-------------------------+ Notes ----- The prefix stated in the text, does not match the one encoded in the example. 10.0.1/24 should be 10.1.1/24 to match the example, or alternatively the example should change from: 0x01 18 0a 01 01 to: 0x01 18 0a 00 01 -------------------------------------- RFC5575 (draft-ietf-idr-flow-spec-09) -------------------------------------- Title : Dissemination of Flow Specification Rules Publication Date : August 2009 Author(s) : P. Marques, N. Sheth, R. Raszuk, B. Greene, J. Mauch, D. McPherson Category : PROPOSED STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Feb 16 14:36:53 2016 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 99D641A6FDF; Tue, 16 Feb 2016 14:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, 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 Z6qdCjqJDycM; Tue, 16 Feb 2016 14:36:46 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id BA9771A1A8D; Tue, 16 Feb 2016 14:36:46 -0800 (PST) Received: from [IPv6:2601:401:3:6a00:c961:74e5:2d9f:f536] (unknown [IPv6:2601:401:3:6a00:c961:74e5:2d9f:f536]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id BD490540734; Tue, 16 Feb 2016 17:36:44 -0500 (EST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3120\)) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <20160216215650.A678C180014@rfc-editor.org> Date: Tue, 16 Feb 2016 17:36:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2E3ECF5B-833B-486E-84C6-A87C10E51B6D@puck.nether.net> References: <20160216215650.A678C180014@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.3120) Archived-At: Cc: idr wg list , nsheth@juniper.net, iesg@ietf.org, roque@cisco.com Subject: Re: [Idr] [Errata Held for Document Update] RFC5575 (4482) 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, 16 Feb 2016 22:36:48 -0000 [cc list trimmed for people I know that changed orgs] The typos should obviously be corrected. I have no opinion of which = way. - Jared > On Feb 16, 2016, at 4:56 PM, RFC Errata System = wrote: >=20 > The following errata report has been held for document update=20 > for RFC5575, "Dissemination of Flow Specification Rules".=20 >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5575&eid=3D4482 >=20 > -------------------------------------- > Status: Held for Document Update > Type: Technical >=20 > Reported by: Wesley Eddy > Date Reported: 2015-09-25 > Held by: Alvaro Retana (IESG) >=20 > Section: 4 (page 11) >=20 > Original Text > ------------- > An example of a flow specification encoding for: "all packets to > 10.0.1/24 from 192/8 and port {range [137, 139] or 8080}". >=20 > +------------------+----------+-------------------------+ > | destination | source | port | > +------------------+----------+-------------------------+ > | 0x01 18 0a 01 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 | > +------------------+----------+-------------------------+ >=20 > Corrected Text > -------------- > An example of a flow specification encoding for: "all packets to > 10.1.1/24 from 192/8 and port {range [137, 139] or 8080}". >=20 > +------------------+----------+-------------------------+ > | destination | source | port | > +------------------+----------+-------------------------+ > | 0x01 18 0a 01 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 | > +------------------+----------+-------------------------+ >=20 > OR: >=20 > An example of a flow specification encoding for: "all packets to > 10.0.1/24 from 192/8 and port {range [137, 139] or 8080}". >=20 > +------------------+----------+-------------------------+ > | destination | source | port | > +------------------+----------+-------------------------+ > | 0x01 18 0a 00 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 | > +------------------+----------+-------------------------+ >=20 > Notes > ----- > The prefix stated in the text, does not match the one encoded in the = example. >=20 > 10.0.1/24 should be 10.1.1/24 to match the example, or alternatively = the example should change from: > 0x01 18 0a 01 01 > to: > 0x01 18 0a 00 01 >=20 > -------------------------------------- > RFC5575 (draft-ietf-idr-flow-spec-09) > -------------------------------------- > Title : Dissemination of Flow Specification Rules > Publication Date : August 2009 > Author(s) : P. Marques, N. Sheth, R. Raszuk, B. Greene, J. = Mauch, D. McPherson > Category : PROPOSED STANDARD > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Feb 17 07:09:12 2016 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 9C4EE1A21B7 for ; Wed, 17 Feb 2016 07:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiK0FI4HVC_b for ; Wed, 17 Feb 2016 07:09:08 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E521A21BA for ; Wed, 17 Feb 2016 07:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5086; q=dns/txt; s=iport; t=1455721748; x=1456931348; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Yb4535RY9yrapzbbC9IpDjKUyrKu3PUhLI6nzTBUTLs=; b=WlEoDK4GG2qrCJt6+NSuWapNcI9sLlg6qF3JAlyC1/rKrTm9FNcNQNGg z/aO6mvKxiV9ty0O2SOhQIrprUfIJmANpo6Zj61IWfoPVFSWjiVFseJwH pOY5ip9BJRCOx9ElWKmApx0gOFjU3fFfOn2vQaRPIvRyIl01KkmIi0Aon I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AQDQjMRW/5pdJa1EGoM6Um0GuhMBD?= =?us-ascii?q?YFnI4VqAoFFOBQBAQEBAQEBZBwLhEIBAQR5EAIBCEYyJQIEDgUJiBEOLLsKAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBFYYShDuBNoc5BYdWCoVKOHmEGIQRAY1YgVyEQ?= =?us-ascii?q?4hUhXGIVQEeAQFCggINDIFIagETh1F8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,461,1449532800"; d="scan'208";a="76993210" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2016 15:08:47 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u1HF8lDV030814 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Feb 2016 15:08:48 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 17 Feb 2016 09:08:48 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Wed, 17 Feb 2016 09:08:48 -0600 From: "Alvaro Retana (aretana)" To: "idr@ietf.org" Thread-Topic: [Technical Errata Reported] RFC4271 (4493) Thread-Index: AQHRAA6relC+roC4oE2Xudnb4lP2K58xOumA Date: Wed, 17 Feb 2016 15:08:48 +0000 Message-ID: References: <20151006081045.66A82187E04@rfc-editor.org> In-Reply-To: <20151006081045.66A82187E04@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.212.52] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <500B3603CA97B140960EB18F68060DFE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "bruno.decraene@orange.com" Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (4493) 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, 17 Feb 2016 15:09:10 -0000 Idr WG: Please take a look at the Errata below. I need your opinion on it. I'm leaning towards rejecting it because I interpret "Unspecific" not as the name of the subcode, but as just an indication that the error is not specific. The IANA registry [1] lists the value 0 as "Reserved", which I think is ok according to the definition in RFC5226: Reserved: Not to be assigned. Reserved values are held for special uses, such as to extend the namespace when it become exhausted. Reserved values are not available for general assignment. In this case the "special use" is when the error is not specific. Any thoughts? Other opinions? Thanks! Alvaro.=20 [1]=20 http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-par ameters-4 On 10/6/15, 4:10 AM, "RFC Errata System" wrote: >The following errata report has been submitted for RFC4271, >"A Border Gateway Protocol 4 (BGP-4)". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=3D4271&eid=3D4493 > >-------------------------------------- >Type: Technical >Reported by: Bruno Decraene > >Section: 4.5 > >Original Text >------------- >=A7\\"4.5 NOTIFICATION Message Format\\" says: > > Message Header Error subcodes: > > 1 - Connection Not Synchronized. > 2 - Bad Message Length. > 3 - Bad Message Type. > > OPEN Message Error subcodes: > > 1 - Unsupported Version Number. > 2 - Bad Peer AS. > 3 - Bad BGP Identifier. > 4 - Unsupported Optional Parameter. > 5 - [Deprecated - see Appendix A]. > 6 - Unacceptable Hold Time. > > UPDATE Message Error subcodes: > > 1 - Malformed Attribute List. > 2 - Unrecognized Well-known Attribute. > 3 - Missing Well-known Attribute. > 4 - Attribute Flags Error. > 5 - Attribute Length Error. > 6 - Invalid ORIGIN Attribute. > 7 - [Deprecated - see Appendix A]. > 8 - Invalid NEXT_HOP Attribute. > 9 - Optional Attribute Error. > 10 - Invalid Network Field. > 11 - Malformed AS_PATH. > >Corrected Text >-------------- > Message Header Error subcodes: > > 0 - Unspecific. > 1 - Connection Not Synchronized. > 2 - Bad Message Length. > 3 - Bad Message Type. > > OPEN Message Error subcodes: > > 0 - Unspecific. > 1 - Unsupported Version Number. > 2 - Bad Peer AS. > 3 - Bad BGP Identifier. > 4 - Unsupported Optional Parameter. > 5 - [Deprecated - see Appendix A]. > 6 - Unacceptable Hold Time. > > UPDATE Message Error subcodes: > > 0 - Unspecific. > 1 - Malformed Attribute List. > 2 - Unrecognized Well-known Attribute. > 3 - Missing Well-known Attribute. > 4 - Attribute Flags Error. > 5 - Attribute Length Error. > 6 - Invalid ORIGIN Attribute. > 7 - [Deprecated - see Appendix A]. > 8 - Invalid NEXT_HOP Attribute. > 9 - Optional Attribute Error. > 10 - Invalid Network Field. > 11 - Malformed AS_PATH. > >Notes >----- >RFC 4271 defines a use and a name for Error subcode 0: >- =A74.5 (any error code): > If no appropriate Error Subcode is defined, then a zero > (Unspecific) value is used for the Error Subcode field. > >- =A76.2 (OPEN error code): > If one of the Optional Parameters in the OPEN message is recognized, > but is malformed, then the Error Subcode MUST be set to 0 > (Unspecific). > >If verified, the \\"IANA Considerations\\" section and the IANA registry >would also need to be updated accordingly (currently says \\"0 >Reserved\\") >http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-pa >rameters-4 > >Instructions: >------------- >This erratum is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party (IESG) >can log in to change the status and edit the report, if necessary. > >-------------------------------------- >RFC4271 (draft-ietf-idr-bgp4-26) >-------------------------------------- >Title : A Border Gateway Protocol 4 (BGP-4) >Publication Date : January 2006 >Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. >Category : DRAFT STANDARD >Source : Inter-Domain Routing >Area : Routing >Stream : IETF >Verifying Party : IESG > From nobody Wed Feb 17 07:19:38 2016 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 61C631A6FCA for ; Wed, 17 Feb 2016 07:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.574 X-Spam-Level: X-Spam-Status: No, score=-1.574 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXS68xU4dfTJ for ; Wed, 17 Feb 2016 07:19:30 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 362031A6FC2 for ; Wed, 17 Feb 2016 07:19:30 -0800 (PST) Received: from [192.168.1.102] (99-59-193-146.lightspeed.livnmi.sbcglobal.net [99.59.193.146]) by slice.pfrc.org (Postfix) with ESMTPSA id 96EA61E832; Wed, 17 Feb 2016 10:22:25 -0500 (EST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=iso-8859-1 From: Jeffrey Haas In-Reply-To: Date: Wed, 17 Feb 2016 10:19:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8B1FE325-EFB5-4C5C-A4D8-1682FA3E0102@pfrc.org> References: <20151006081045.66A82187E04@rfc-editor.org> To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "idr@ietf.org" , "bruno.decraene@orange.com" Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (4493) 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, 17 Feb 2016 15:19:36 -0000 Updating the registry to Unspecific would reflect common implementation = practice. For years, 0 has basically meant "this doesn't fit into = anything else". =20 The existing value of reserved in the registry was likely an oversight = as part of registry maintenance over the long life of BGP. Even RFC = 1771 section 6 covers the 0 as an appropriate value, yet it's not listed = in the enumerations of the different code types. FWIW, Junos uses the word "unspecified" in several of the debugging = outputs rather than "unspecific". I would lean toward unspecified. :-) Note that the BGP MIBs do not provide any related enumerations so there = is no support one way or the other in existing standardized items beyond = the normative text in the RFCs that value 0 is to be used. -- Jeff > On Feb 17, 2016, at 10:08 AM, Alvaro Retana (aretana) = wrote: >=20 > Idr WG: >=20 > Please take a look at the Errata below. I need your opinion on it. >=20 >=20 > I'm leaning towards rejecting it because I interpret "Unspecific" not = as > the name of the subcode, but as just an indication that the error is = not > specific. The IANA registry [1] lists the value 0 as "Reserved", = which I > think is ok according to the definition in RFC5226: >=20 > Reserved: Not to be assigned. Reserved values are held for > special uses, such as to extend the namespace when it = become > exhausted. Reserved values are not available for general > assignment. >=20 > In this case the "special use" is when the error is not specific. >=20 >=20 >=20 > Any thoughts? Other opinions? >=20 > Thanks! >=20 > Alvaro.=20 >=20 > [1]=20 > = http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-pa= r > ameters-4 >=20 >=20 >=20 > On 10/6/15, 4:10 AM, "RFC Errata System" = wrote: >=20 >> The following errata report has been submitted for RFC4271, >> "A Border Gateway Protocol 4 (BGP-4)". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D4271&eid=3D4493 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Bruno Decraene >>=20 >> Section: 4.5 >>=20 >> Original Text >> ------------- >> =A7\\"4.5 NOTIFICATION Message Format\\" says: >>=20 >> Message Header Error subcodes: >>=20 >> 1 - Connection Not Synchronized. >> 2 - Bad Message Length. >> 3 - Bad Message Type. >>=20 >> OPEN Message Error subcodes: >>=20 >> 1 - Unsupported Version Number. >> 2 - Bad Peer AS. >> 3 - Bad BGP Identifier. >> 4 - Unsupported Optional Parameter. >> 5 - [Deprecated - see Appendix A]. >> 6 - Unacceptable Hold Time. >>=20 >> UPDATE Message Error subcodes: >>=20 >> 1 - Malformed Attribute List. >> 2 - Unrecognized Well-known Attribute. >> 3 - Missing Well-known Attribute. >> 4 - Attribute Flags Error. >> 5 - Attribute Length Error. >> 6 - Invalid ORIGIN Attribute. >> 7 - [Deprecated - see Appendix A]. >> 8 - Invalid NEXT_HOP Attribute. >> 9 - Optional Attribute Error. >> 10 - Invalid Network Field. >> 11 - Malformed AS_PATH. >>=20 >> Corrected Text >> -------------- >> Message Header Error subcodes: >>=20 >> 0 - Unspecific. >> 1 - Connection Not Synchronized. >> 2 - Bad Message Length. >> 3 - Bad Message Type. >>=20 >> OPEN Message Error subcodes: >>=20 >> 0 - Unspecific. >> 1 - Unsupported Version Number. >> 2 - Bad Peer AS. >> 3 - Bad BGP Identifier. >> 4 - Unsupported Optional Parameter. >> 5 - [Deprecated - see Appendix A]. >> 6 - Unacceptable Hold Time. >>=20 >> UPDATE Message Error subcodes: >>=20 >> 0 - Unspecific. >> 1 - Malformed Attribute List. >> 2 - Unrecognized Well-known Attribute. >> 3 - Missing Well-known Attribute. >> 4 - Attribute Flags Error. >> 5 - Attribute Length Error. >> 6 - Invalid ORIGIN Attribute. >> 7 - [Deprecated - see Appendix A]. >> 8 - Invalid NEXT_HOP Attribute. >> 9 - Optional Attribute Error. >> 10 - Invalid Network Field. >> 11 - Malformed AS_PATH. >>=20 >> Notes >> ----- >> RFC 4271 defines a use and a name for Error subcode 0: >> - =A74.5 (any error code): >> If no appropriate Error Subcode is defined, then a zero >> (Unspecific) value is used for the Error Subcode field. >>=20 >> - =A76.2 (OPEN error code): >> If one of the Optional Parameters in the OPEN message is recognized, >> but is malformed, then the Error Subcode MUST be set to 0 >> (Unspecific). >>=20 >> If verified, the \\"IANA Considerations\\" section and the IANA = registry >> would also need to be updated accordingly (currently says \\"0 >> Reserved\\") >> = http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-pa= >> rameters-4 >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >>=20 >> -------------------------------------- >> RFC4271 (draft-ietf-idr-bgp4-26) >> -------------------------------------- >> Title : A Border Gateway Protocol 4 (BGP-4) >> Publication Date : January 2006 >> Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. >> Category : DRAFT STANDARD >> Source : Inter-Domain Routing >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >>=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Feb 17 07:39:52 2016 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 7DC5B1A6F86 for ; Wed, 17 Feb 2016 07:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 F53BSLuHAvUS for ; Wed, 17 Feb 2016 07:39:48 -0800 (PST) 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 C226D1A21C6 for ; Wed, 17 Feb 2016 07:39:47 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 0191A3B4605; Wed, 17 Feb 2016 16:39:45 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.69]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id B6CE34C048; Wed, 17 Feb 2016 16:39:45 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0279.002; Wed, 17 Feb 2016 16:39:45 +0100 From: To: "Alvaro Retana (aretana)" , "idr@ietf.org" Thread-Topic: [Technical Errata Reported] RFC4271 (4493) Thread-Index: AQHRAA6relC+roC4oE2Xudnb4lP2K58xOumA///ykyA= Date: Wed, 17 Feb 2016 15:39:44 +0000 Message-ID: <22082_1455723585_56C49441_22082_2687_1_53C29892C857584299CBF5D05346208A0F7CC535@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <20151006081045.66A82187E04@rfc-editor.org> 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.168.234.1] 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: 2016.2.17.151216 Archived-At: Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (4493) 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, 17 Feb 2016 15:39:50 -0000 Thanks for the follow up. My 2 cents inline > From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] > Sent: Wednesda= y, February 17, 2016 4:09 PM >=20 > Idr WG: >=20 > Please take a look at the Errata below. I need your opinion on it. >=20 >=20 > I'm leaning towards rejecting it because I interpret "Unspecific" not as > the name of the subcode, but as just an indication that the error is not > specific. The IANA registry [1] lists the value 0 as "Reserved", And where does this comes from? In theory, this should come from RFC 4271. > which I > think is ok according to the definition in RFC5226: >=20 > Reserved: Not to be assigned. Reserved values are held for > special uses, such as to extend the namespace when it become > exhausted. Reserved values are not available for general > assignment. >=20 > In this case the "special use" is when the error is not specific. My point was that this value is not unallocated/unused. i.e. it can't (must= not) be used for a new purpose as RFC 4271 already specifies when this val= ue is sent. You can't change its meaning. My reading is that this value is = assigned and means Unspecific/Other error. One could not defined another us= e for this value, without first deprecating this usage. That being said, I don't feel that this is a real problem (e.g. given the s= pace of available code point) so I won't argue anymore ;-) Thanks -- Bruno =20 >=20 >=20 > Any thoughts? Other opinions? >=20 > Thanks! >=20 > Alvaro. >=20 > [1] > http://www.iana.org/assignments/bgp-parameters/bgp- > parameters.xhtml#bgp-par > ameters-4 >=20 >=20 >=20 > On 10/6/15, 4:10 AM, "RFC Errata System" > wrote: >=20 > >The following errata report has been submitted for RFC4271, > >"A Border Gateway Protocol 4 (BGP-4)". > > > >-------------------------------------- > >You may review the report below and at: > >http://www.rfc-editor.org/errata_search.php?rfc=3D4271&eid=3D4493 > > > >-------------------------------------- > >Type: Technical > >Reported by: Bruno Decraene > > > >Section: 4.5 > > > >Original Text > >------------- > >=A7\\"4.5 NOTIFICATION Message Format\\" says: > > > > Message Header Error subcodes: > > > > 1 - Connection Not Synchronized. > > 2 - Bad Message Length. > > 3 - Bad Message Type. > > > > OPEN Message Error subcodes: > > > > 1 - Unsupported Version Number. > > 2 - Bad Peer AS. > > 3 - Bad BGP Identifier. > > 4 - Unsupported Optional Parameter. > > 5 - [Deprecated - see Appendix A]. > > 6 - Unacceptable Hold Time. > > > > UPDATE Message Error subcodes: > > > > 1 - Malformed Attribute List. > > 2 - Unrecognized Well-known Attribute. > > 3 - Missing Well-known Attribute. > > 4 - Attribute Flags Error. > > 5 - Attribute Length Error. > > 6 - Invalid ORIGIN Attribute. > > 7 - [Deprecated - see Appendix A]. > > 8 - Invalid NEXT_HOP Attribute. > > 9 - Optional Attribute Error. > > 10 - Invalid Network Field. > > 11 - Malformed AS_PATH. > > > >Corrected Text > >-------------- > > Message Header Error subcodes: > > > > 0 - Unspecific. > > 1 - Connection Not Synchronized. > > 2 - Bad Message Length. > > 3 - Bad Message Type. > > > > OPEN Message Error subcodes: > > > > 0 - Unspecific. > > 1 - Unsupported Version Number. > > 2 - Bad Peer AS. > > 3 - Bad BGP Identifier. > > 4 - Unsupported Optional Parameter. > > 5 - [Deprecated - see Appendix A]. > > 6 - Unacceptable Hold Time. > > > > UPDATE Message Error subcodes: > > > > 0 - Unspecific. > > 1 - Malformed Attribute List. > > 2 - Unrecognized Well-known Attribute. > > 3 - Missing Well-known Attribute. > > 4 - Attribute Flags Error. > > 5 - Attribute Length Error. > > 6 - Invalid ORIGIN Attribute. > > 7 - [Deprecated - see Appendix A]. > > 8 - Invalid NEXT_HOP Attribute. > > 9 - Optional Attribute Error. > > 10 - Invalid Network Field. > > 11 - Malformed AS_PATH. > > > >Notes > >----- > >RFC 4271 defines a use and a name for Error subcode 0: > >- =A74.5 (any error code): > > If no appropriate Error Subcode is defined, then a zero > > (Unspecific) value is used for the Error Subcode field. > > > >- =A76.2 (OPEN error code): > > If one of the Optional Parameters in the OPEN message is recognized, > > but is malformed, then the Error Subcode MUST be set to 0 > > (Unspecific). > > > >If verified, the \\"IANA Considerations\\" section and the IANA registry > >would also need to be updated accordingly (currently says \\"0 > >Reserved\\") > >http://www.iana.org/assignments/bgp-parameters/bgp- > parameters.xhtml#bgp-pa > >rameters-4 > > > >Instructions: > >------------- > >This erratum is currently posted as "Reported". If necessary, please > >use "Reply All" to discuss whether it should be verified or > >rejected. When a decision is reached, the verifying party (IESG) > >can log in to change the status and edit the report, if necessary. > > > >-------------------------------------- > >RFC4271 (draft-ietf-idr-bgp4-26) > >-------------------------------------- > >Title : A Border Gateway Protocol 4 (BGP-4) > >Publication Date : January 2006 > >Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. > >Category : DRAFT STANDARD > >Source : Inter-Domain Routing > >Area : Routing > >Stream : IETF > >Verifying Party : IESG > > ___________________________________________________________________________= ______________________________________________ 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 Feb 17 09:19:25 2016 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 12CBA1A8A44 for ; Wed, 17 Feb 2016 09:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, T_DKIM_INVALID=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 aX6xUj7Wf5nc for ; Wed, 17 Feb 2016 09:19:21 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0754.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::754]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8ABF1A1B29 for ; Wed, 17 Feb 2016 09:19:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dRuP23tcOyDOrIUtxDfmPloWekbn0NVkQt50TqQ7ZJc=; b=Ygjd7nHLlHyx80xx6Osvd3JhugG32uAZnxkqhk/uar5zCjH58eZJdZWKG3/FqeF6V5/a4gPW4B1CoTz7GO7DHQEbZ3zdN49/it/qjgJ2hv+ew/AN7DKmxwYmUoUIGU78lhhTqzsIHkAz4oxfpQrUhjbr0qiQhqKSweU53hA0w0E= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.167.152.31) by HE1PR07MB1628.eurprd07.prod.outlook.com (10.166.124.24) with Microsoft SMTP Server (TLS) id 15.1.409.15; Wed, 17 Feb 2016 17:18:53 +0000 Message-ID: <008901d169a6$cc3d1da0$4001a8c0@gateway.2wire.net> From: t.petch To: "Alvaro Retana (aretana)" , References: <20151006081045.66A82187E04@rfc-editor.org> Date: Wed, 17 Feb 2016 17:15:14 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.167.152.31] X-ClientProxiedBy: DB3PR01CA0052.eurprd01.prod.exchangelabs.com (10.242.133.155) To HE1PR07MB1628.eurprd07.prod.outlook.com (25.166.124.24) X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1628; 2:/k4ltVISUeVam94ySy8bwpjHp9xO5A5s01cd7wnqgPtOfnEloWMCm3Eal9BrEPRnI9YwhboUTTBu1jQGcsT2yjg/CbaX0evpHTH0sb04JCm46t68cjvbbY68ltJvI4jjkrFxcKg7NyR64nM7zF/2XA==; 3:NmlefVbrNCiZcSZeQ85hzo/Q8sVkmgwSuSjJ2HxZCpYDDGV25ZouCgkDm7K+donedIn9IboOxyNHYwpWyFaFKPZ6rJiYqcAmkOswkTnGokKamch7j0iS4HFfOwegdtHO; 25:kp09cb7r3mzkVcC9izV/2I17lXCKNiZER+9jf/lSHtwVQY9kEfZGT5tc/ZJlMLTAmyByMoJAOvb5hj79D/xq+2EsP9PNWW1fU+cWn/4HbmCUJ8gjbaGNRUlsg11SaPnVWU8CG+p+KcL9xRoLtn/SuBAMLLOCdT9W+d5nd2eLLvJM0e8g0Vxai9HMvsNdHf914OHzFvd5E58ztk/q2yxexonffj0hh3PvN1UE+lDEQCO0o7d8MHvfz093ffLGuNE20nBgEGWO56nv6GYBPnzyfAlylQKORZuFt9Pzmar+v2mm/GdTutbs4pLt5FSrg8Wt X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB1628; X-MS-Office365-Filtering-Correlation-Id: ac5ee727-ceb4-4c75-f0ed-08d337be698c X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:HE1PR07MB1628; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1628; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1628; 4:e2jKszUDD3tawHoeDV4Ft0n1Tj/j5kEQYewCEvLLFtRVf4+FiWhlw75+h84ykO2zXC062I7DzjhfLeoHC1c7u1FOkIUD/y5Zx1O+DfurIVrgCskIaHD1bcc1hxn5fj9B/XP8IFBRnwZWKiNryi40DLYKAodOeA67+to2wX9CPn+V/H3ecLc2UZ+dnyTCVxGsM3QgQ8JEqmm8WWBlT4wM/RoVWr+9BYoQxldRWQWPzwEeeisyg0JdApOo4WSbXfFMYOooL5mEKmh01HPiHqwxVc4V9arLqGMWKmzmqMhmdixRusfXropXZzPirQZ9HMPzWvgc97W3nnU8Lq1fgRdTyqhRwV5zweSJ+dU7UyGHCAsFJvKB2adXMhYEx7hzir1bpw1+2AnFS6mivpbTBhxuD8JJflkyT3hAmSxefHJRyas= X-Forefront-PRVS: 085551F5A8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(13464003)(377454003)(479174004)(24454002)(51444003)(5004730100002)(76176999)(19580395003)(50986999)(81686999)(81816999)(116806002)(81156007)(33646002)(19580405001)(86362001)(5001770100001)(5001960100002)(189998001)(1556002)(50466002)(1456003)(44716002)(2870700001)(40100003)(50226001)(42186005)(92566002)(4326007)(44736004)(5008740100001)(47776003)(23756003)(586003)(14496001)(2906002)(1096002)(62236002)(61296003)(66066001)(84392002)(77096005)(3846002)(122386002)(16799955002)(87976001)(15188155005)(6116002)(15975445007)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1628; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR07MB1628; 23:I+OoDC0/YU8AUgbjeeebLUI2z8RWqlIn8PBnrX9?= =?iso-8859-1?Q?3ikO8vFk9nTP0sotq7X9I6QkvkXla9dUt8fGsXGOV9dHmyoAYKJbmbrfAy?= =?iso-8859-1?Q?FCkoUcpPL2FF9DWk2OKbTqJnUWdADvaCgiRnDRUopJakRu51whkP8gxMM1?= =?iso-8859-1?Q?TYllrul9Vf/dBbATAdiVoJyN6xHJOKiKxcpRjJPohEYlOIr6j3l6beNklv?= =?iso-8859-1?Q?X+1BaDeefeiprNUj1ZIZMfK6yN5CPNY0gYYB1LWxbwAi8GY6WMnXRrSqRs?= =?iso-8859-1?Q?VdZIt/M4gZYpNRprfby/bot1GNpFXtDAKE+WD9ltycxxi2daZ88T9EnP8K?= =?iso-8859-1?Q?z1xDEEftrwJ3XcOu/YPj6cbS4fmoKc1leOCSiWuIo0bsY/BIyY8W2SS0NR?= =?iso-8859-1?Q?US+SxrBqijGeCSaYt+AsIfx5aBZtuVyvsw2OMsP46w49sOkvTdMLSx8zFk?= =?iso-8859-1?Q?pVsoylFq0o4PbutYf8YLVAGuPX+dCAQ1Dk9gsaekHryHZEXP5pRhBHDGDa?= =?iso-8859-1?Q?NWzpyZySFsZVaSaTa143D2wmjiFs9AQJfgfLxxx8bseAT5qqbyvqRS1Z5/?= =?iso-8859-1?Q?LL1VNaW8zxRBl6K2GFFGzLL8dN+1m5blUFlQcXFOmZc+3xFEvQf0L33SUI?= =?iso-8859-1?Q?6Vqtc7gsby1GvmzpBeuHdl4+xgQaS1z8FBwVqE9BxBPtGa5tCGoVLuVhem?= =?iso-8859-1?Q?1jWyrlgab0lLFiujcSnutCmPSxJ9o/uzhNYsjMyhJzjwgxmD8LbCyE38Hr?= =?iso-8859-1?Q?PfUDOHe2K3ABayAQ9KVBaKgtcmYvTgzZbIJhKkrFTqa0MAynsClMDwc3cx?= =?iso-8859-1?Q?v3VQOpVzC0w1uTCi1jgQFtWAJD2a3++bJ5JbofHS9cfN+m2rkAcgOANrIp?= =?iso-8859-1?Q?arkU3vjHvZHkRf5iKzYfPEw04LBUYLh3fUfA+bOkvexRPnhF77OZCUmqQL?= =?iso-8859-1?Q?HV1Q0rTxWF/eGKadjAGm6hhlaYncY4r8pGYznE8DekogLCa0WcmjFJLYvM?= =?iso-8859-1?Q?LwSkwEUt72CPJARAvJkf56DOo8nfjlakgQWi7NOk2g0i68ybgyyym8V8+G?= =?iso-8859-1?Q?DkT5vUvIyplZbWey+xh/UubM8hcRh1i/bVf6uOIy5riTiy+cOxzLJaqFHH?= =?iso-8859-1?Q?QBHBlbmoXWqfArWsxUnAA7MQ7w3hg39C3PXzJ8EAAeQ0Mv8hM+Cs3HOFqL?= =?iso-8859-1?Q?Qs5bG5P5lhA3cfXoJ+2/p38TkVGlkxXHaaJNZIO38Umiha5pdcxFW3+q2z?= =?iso-8859-1?Q?8M88yC0mVk/kwx0jRpcWnX2wDgHYx7SDv+OJjfViQvd2rYqUQylM/VphjK?= =?iso-8859-1?Q?lnKWMAg5cl/m0djKEydvu3aBm229wMBs3FdCEsfiVGSfCeSWU1vM42NE1s?= =?iso-8859-1?Q?gFt99QGsXv5Mk7Cwjdp5oL0HXLwa9Gf5NWqkXHZLieViQJvXFpw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1628; 5:kuO0MNnV/u5B00kz3QybX2tpDb8u9U5+F0obMf+6ruzebt6ClbMI7pJ3woXRQO9L9Y0MLgAQwxm+R907rIB9aYB4fk9WJjnHq3HET3fREqA+QC00ythF6yNckVGySkzpfWq0/3+OGWz8Wa0rZmhFAg==; 24:Moqb8mndJbYUZEIZElBQotswFHSW1NqeZxa+1ZABUj94h7yz3XcwFI6T8q65gmeCoSBBfHbcq/LixDZuCvRL+wj6F9dccpLVal5X9sG+eAA= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Feb 2016 17:18:53.7592 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1628 Archived-At: Cc: bruno.decraene@orange.com Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (4493) 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, 17 Feb 2016 17:19:24 -0000 ----- Original Message ----- From: "Alvaro Retana (aretana)" To: Cc: Sent: Wednesday, February 17, 2016 3:08 PM Idr WG: Please take a look at the Errata below. I need your opinion on it. I'm leaning towards rejecting it because I interpret "Unspecific" not as the name of the subcode, but as just an indication that the error is not specific. The IANA registry [1] lists the value 0 as "Reserved", which I think is ok according to the definition in RFC5226: Reject. s.6.2 specifies a specific(!) instance of using 0(Unspecific) (so I think that IANA is in error here). Arguably, you could raise an erratum to add 0(Unspecific) for the OPEN Message Error subcodes list but I think that it would be a technical change to add it for the other messages. As currently defined, it could be seen as an implementation error were subcode 0 be used for the other messages (an interpretation which I have no problem with). If there are errors that cannot be reported using the subcodes in RC4271, then that is a separate issue that could be worth investigating. Tom Petch Reserved: Not to be assigned. Reserved values are held for special uses, such as to extend the namespace when it become exhausted. Reserved values are not available for general assignment. In this case the "special use" is when the error is not specific. Any thoughts? Other opinions? Thanks! Alvaro. [1] http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp- par ameters-4 On 10/6/15, 4:10 AM, "RFC Errata System" wrote: >The following errata report has been submitted for RFC4271, >"A Border Gateway Protocol 4 (BGP-4)". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=4493 > >-------------------------------------- >Type: Technical >Reported by: Bruno Decraene > >Section: 4.5 > >Original Text >------------- >§\\"4.5 NOTIFICATION Message Format\\" says: > > Message Header Error subcodes: > > 1 - Connection Not Synchronized. > 2 - Bad Message Length. > 3 - Bad Message Type. > > OPEN Message Error subcodes: > > 1 - Unsupported Version Number. > 2 - Bad Peer AS. > 3 - Bad BGP Identifier. > 4 - Unsupported Optional Parameter. > 5 - [Deprecated - see Appendix A]. > 6 - Unacceptable Hold Time. > > UPDATE Message Error subcodes: > > 1 - Malformed Attribute List. > 2 - Unrecognized Well-known Attribute. > 3 - Missing Well-known Attribute. > 4 - Attribute Flags Error. > 5 - Attribute Length Error. > 6 - Invalid ORIGIN Attribute. > 7 - [Deprecated - see Appendix A]. > 8 - Invalid NEXT_HOP Attribute. > 9 - Optional Attribute Error. > 10 - Invalid Network Field. > 11 - Malformed AS_PATH. > >Corrected Text >-------------- > Message Header Error subcodes: > > 0 - Unspecific. > 1 - Connection Not Synchronized. > 2 - Bad Message Length. > 3 - Bad Message Type. > > OPEN Message Error subcodes: > > 0 - Unspecific. > 1 - Unsupported Version Number. > 2 - Bad Peer AS. > 3 - Bad BGP Identifier. > 4 - Unsupported Optional Parameter. > 5 - [Deprecated - see Appendix A]. > 6 - Unacceptable Hold Time. > > UPDATE Message Error subcodes: > > 0 - Unspecific. > 1 - Malformed Attribute List. > 2 - Unrecognized Well-known Attribute. > 3 - Missing Well-known Attribute. > 4 - Attribute Flags Error. > 5 - Attribute Length Error. > 6 - Invalid ORIGIN Attribute. > 7 - [Deprecated - see Appendix A]. > 8 - Invalid NEXT_HOP Attribute. > 9 - Optional Attribute Error. > 10 - Invalid Network Field. > 11 - Malformed AS_PATH. > >Notes >----- >RFC 4271 defines a use and a name for Error subcode 0: >- §4.5 (any error code): > If no appropriate Error Subcode is defined, then a zero > (Unspecific) value is used for the Error Subcode field. > >- §6.2 (OPEN error code): > If one of the Optional Parameters in the OPEN message is recognized, > but is malformed, then the Error Subcode MUST be set to 0 > (Unspecific). > >If verified, the \\"IANA Considerations\\" section and the IANA registry >would also need to be updated accordingly (currently says \\"0 >Reserved\\") >http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp -pa >rameters-4 > >Instructions: >------------- >This erratum is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party (IESG) >can log in to change the status and edit the report, if necessary. > >-------------------------------------- >RFC4271 (draft-ietf-idr-bgp4-26) >-------------------------------------- >Title : A Border Gateway Protocol 4 (BGP-4) >Publication Date : January 2006 >Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. >Category : DRAFT STANDARD >Source : Inter-Domain Routing >Area : Routing >Stream : IETF >Verifying Party : IESG > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Wed Feb 17 11:59:04 2016 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 987B61AD277 for ; Wed, 17 Feb 2016 11:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swFNBsmdYIVn for ; Wed, 17 Feb 2016 11:59:01 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A473F1AD16B for ; Wed, 17 Feb 2016 11:59:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5092; q=dns/txt; s=iport; t=1455739141; x=1456948741; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=irVwlCfPg7Dx5kRcD1FMTiYgMqCVaDySqDcG2r59Ags=; b=Wsn+MZVV8RwZlv+eOoXMNyFYVLHwy2XzTO/CXlZUSMY7AxbvreqbCtxN dAgqe6oXAZ0KaPeJRucHX/blkyxkkODEU/yrfvTxBmeF2a96baaTa+Nk3 uwMbtgu4gn7skidAagVUs0wjMhjJ946GRtM0MeD8I87/aHNCINgEnURbD A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2AgDSz8RW/5JdJa1EGoM6Um0GuhgBD?= =?us-ascii?q?YFnI4UgSgKBTDgUAQEBAQEBAWQcC4RCAQEEOj8QAgEINhAyJQIEDgUJC4gGDiy?= =?us-ascii?q?7IwEBAQEBAQEBAQEBAQEBAQEBAQEBARWGEoQ7gTaHOQWHVgqGe4QYhBEBjViBX?= =?us-ascii?q?IRDiFSORgEeAQFCggINDIFIagEThzB8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,462,1449532800"; d="scan'208";a="72410045" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2016 19:59:00 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u1HJx0bI023337 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Feb 2016 19:59:00 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 17 Feb 2016 13:59:01 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Wed, 17 Feb 2016 13:59:01 -0600 From: "Alvaro Retana (aretana)" To: "idr@ietf.org" Thread-Topic: [Editorial Errata Reported] RFC1997 (4576) Thread-Index: AQHRRYxpLdbPcWj0vUGQFZ7xqea5bZ8xAOuA Date: Wed, 17 Feb 2016 19:59:01 +0000 Message-ID: References: <20160102183505.BC84B180094@rfc-editor.org> In-Reply-To: <20160102183505.BC84B180094@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "gjoko.stamenkov@mikasta.com" Subject: Re: [Idr] [Editorial Errata Reported] RFC1997 (4576) 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, 17 Feb 2016 19:59:03 -0000 Idr WG: Hi! Here's another report that I want to run through the WG. Please see below. In essence, the report says that the definition of NO_EXPORT (and NO_EXPORT_SUBCONFED) is wrong. Looking at on-line documentation I found this (for NO_EXPORT): cisco: "Routes with this community are advertised to only peers in the same autonomous system or to only other subautonomous systems within a confederation. These routes are not advertised to external peers." [1] Juniper: "Routes in this community must not be advertised outside a BGP confederation boundary." [2] Quagga: "All routes carry this value must not be advertised to outside a BGP confederation boundary. If neighboring BGP peer is part of BGP confederation, the peer is considered as inside a BGP confederation boundary, so the route will be announced to the peer." [3] [Sorry if I didn't look up all the vendors -- I also didn't make an effort to verify that the documentation says what the routers actually do.] The descriptions above are in line with what is currently in RFC1997. Before I reject the report (and to be on the safe side), I want to ask the vendors in the WG: Does the documentation really match the functionality? ;-) Are there implementations that don't match the functionality described in RFC1997? Thanks! Alvaro. [1]=20 http://www.cisco.com/c/en/us/td/docs/ios/12_2/iproute/command/reference/fip rrp_r/1rfbgp1.html [2]=20 http://www.juniper.net/documentation/en_US/junos13.3/topics/usage-guideline s/policy-defining-bgp-communities-and-extended-communities-for-use-in-routi ng-policy-match-conditions.html [3]=20 http://www.nongnu.org/quagga/docs/docs-multi/BGP-Communities-Attribute.html On 1/2/16, 1:35 PM, "RFC Errata System" wrote: >The following errata report has been submitted for RFC1997, >"BGP Communities Attribute". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=3D1997&eid=3D4576 > >-------------------------------------- >Type: Editorial >Reported by: Gjoko Stamenkov > >Section: GLOBAL > >Original Text >------------- >Well-known Communities > > The following communities have global significance and their > operations shall be implemented in any community-attribute-aware BGP > speaker. > >NO_EXPORT (0xFFFFFF01) > All routes received carrying a communities attribute > containing this value MUST NOT be advertised outside a BGP > confederation boundary (a stand-alone autonomous system that > is not part of a confederation should be considered a > confederation itself). >NO_ADVERTISE (0xFFFFFF02) > All routes received carrying a communities attribute > containing this value MUST NOT be advertised to other BGP > peers. >NO_EXPORT_SUBCONFED (0xFFFFFF03) > All routes received carrying a communities attribute > containing this value MUST NOT be advertised to external BGP > peers (this includes peers in other members autonomous > systems inside a BGP confederation). > >Corrected Text >-------------- >Well-known Communities > > The following communities have global significance and their > operations shall be implemented in any community-attribute-aware BGP > speaker. > >NO_EXPORT (0xFFFFFF01) > All routes received carrying a communities attribute > containing this value MUST NOT be advertised to external BGP > peers (this includes peers in other members autonomous > systems inside a BGP confederation). >NO_ADVERTISE (0xFFFFFF02) > All routes received carrying a communities attribute > containing this value MUST NOT be advertised to other BGP > peers. >NO_EXPORT_SUBCONFED (0xFFFFFF03) > All routes received carrying a communities attribute > containing this value MUST NOT be advertised outside a BGP > confederation boundary (a stand-alone autonomous system that > is not part of a confederation should be considered a > confederation itself). > >Notes >----- >Definitions of NO_EXPORT and NO_EXPORT_SUBCONFED are interchanged in the >original text. > >Instructions: >------------- >This erratum is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party (IESG) >can log in to change the status and edit the report, if necessary. > >-------------------------------------- >RFC1997 (no draft string recorded) >-------------------------------------- >Title : BGP Communities Attribute >Publication Date : August 1996 >Author(s) : R. Chandra, P. Traina, T. Li >Category : PROPOSED STANDARD >Source : Inter-Domain Routing >Area : Routing >Stream : IETF >Verifying Party : IESG > From nobody Wed Feb 17 12:42:00 2016 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 D759C1A8982 for ; Wed, 17 Feb 2016 12:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, T_DKIM_INVALID=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 XTwuIf-jJBzy for ; Wed, 17 Feb 2016 12:41:51 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0125.outbound.protection.outlook.com [104.47.1.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9168B1A1A7C for ; Wed, 17 Feb 2016 12:41:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fHqUOWZ9vTBTNEXn3ntMqGRdGq0DXPPBwzYKhZ4KK2k=; b=Gs/96KAyMUuU9Eu3AOBRa048l8hSCNE+NJHpxFJAE1S+n/Mlekke2LeOxy5rJ+Tl1ztinoGWy06jdRWpZdbBd3rfigdGH7xcXkQRyQmDoyiyjv3vG7FbAvlLzJkKaeCg75mTl5aTOr3tjtHJtQtXiWQWXzLNH8ytZ+oaPPBDQIM= Authentication-Results: pfrc.org; dkim=none (message not signed) header.d=none;pfrc.org; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.167.152.31) by VI1PR07MB1632.eurprd07.prod.outlook.com (10.166.142.150) with Microsoft SMTP Server (TLS) id 15.1.409.15; Wed, 17 Feb 2016 20:41:46 +0000 Message-ID: <00f301d169c3$231d0a60$4001a8c0@gateway.2wire.net> From: t.petch To: Jeffrey Haas , "Alvaro Retana (aretana)" References: <20151006081045.66A82187E04@rfc-editor.org> <8B1FE325-EFB5-4C5C-A4D8-1682FA3E0102@pfrc.org> Date: Wed, 17 Feb 2016 20:38:09 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.167.152.31] X-ClientProxiedBy: DB3PR01CA0048.eurprd01.prod.exchangelabs.com (10.242.133.151) To VI1PR07MB1632.eurprd07.prod.outlook.com (25.166.142.150) X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1632; 2:MGoO+wUayabTdsIOqYjgXhy8BcMxDbmj0c0gMtNDBUudCuDnlxmOHBJCy+/GGbj4M9P1w2V28NXe4hO4+MtR954SI7MR9G3S9jD2jlXKxSi3IfdpJknq2qnYL5FrWl/xQomHQA2/NZfc5k/HeO32ng==; 3:Va+5sZw+gZEB+FvbXxBg+4t+50IN6L4wWlFQcU4FdcHbxxOFJGBP8qXY5VZxeQA985geUsA/LT41xVKWXVjA9hVAMPsHlBiv29QfeR3qKIsIJdlqxg0jpLPRy+Vgzpxp; 25:QYZYk7t2JHzHzmNovB14ORhlZ1q1WdvxS4Q5EX7DdF4n7YJ1DhqfUWBfFnqdu1cV8nO9B/1JcKGhJlS+EJPx0rRgjN2eXLh/4MIS6Zlg7fQDRZIPaUplRGp4MeQiDl8sZ/cI7GvFFys5XDZL0liUfT2CTNwBflMkbzHL1men+ZOdHzPlCfYB+BA67Be1Mj2u2RHkDBU+9Hj1mqY+e+tMxlds5GO4XQYdgGqARo4Rry9Ag9awOsxKqil4m7BmS95VgDTjYnDy790RNeUV4FinXQ4v3Vlc0XLWNB01BLztOHxOmBquM6vbJNBgAXqvmAeo X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1632; X-MS-Office365-Filtering-Correlation-Id: 9503a34d-41a7-4f22-5c4c-08d337dac127 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR07MB1632; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1632; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1632; 4:BPIq4B0eayFhSyjhG763h7MVPpvVpy1USSf7O/nL/l6eoe0RXImwS/6AbV7Ge4W0EsTrPonFnilGfh+lCruir4/Ghl46BaKj8VK/AdlVpksfF8DKC4EE2R8LXMIBKMe8TjhszmU3SSEYre0/0/mscCGlnYUM1GlFhI6QxiCm77DjQqccY+/pejbkTt+0r4p8SYJxUk2b8R2N4PuTFdPNqSkOFbmMzAI0v2EdE6baBJXRnSk4q3F8YOPrAMcz20cHQGe2X5OJ0596gQy5eRQcXuA0bpoIMwThTN7Q3fG+F2fTYspK7+2ZJP13z4+89EuexaGVoOdBtvcwKd6+8++2E1mNM/LgHz21+cjYSAAlD/xLGSHCxwX7D9c45MA05hL/bOCa85Rhj8WSOZdAlB0loSdv2t1BivI4F4ggdFSf7jp6T6A45OsBHVqLaNs1IG94 X-Forefront-PRVS: 085551F5A8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(50944005)(24454002)(479174004)(13464003)(377454003)(84392002)(92566002)(81816999)(5004730100002)(15188155005)(189998001)(76176999)(23756003)(5001770100001)(5008740100001)(50986999)(81686999)(15975445007)(1456003)(77096005)(50226001)(1096002)(2906002)(2870700001)(5001960100002)(66066001)(4326007)(40100003)(3846002)(44736004)(6116002)(586003)(122386002)(19580395003)(61296003)(19580405001)(42186005)(116806002)(50466002)(87976001)(33646002)(14496001)(86362001)(44716002)(47776003)(62236002)(16799955002)(1556002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1632; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR07MB1632; 23:gxtq7td3pvGwkWGm2HHC72cX9a3aoImrHr0IWOh?= =?iso-8859-1?Q?8R4l3X4lw9L0fze+gL2xwBnGwxiPwinUoqdan/qICUdbctyDk48n4kByzZ?= =?iso-8859-1?Q?cldWFgfk7iyDXxJhKrVmR/kUPXrC1i90A00iCsNhhvGnYfhI2YqajICIiF?= =?iso-8859-1?Q?2Qcv8WJYrIiUBB403nHVx0tgvtaBKtnitdwuCQQMiBRBGwX24omiVwlP3/?= =?iso-8859-1?Q?BHS+06f1CpJBd05fk1/hxPUm9qluDV1Ufh9oZNYNurDIUFEL0dykgEu6yw?= =?iso-8859-1?Q?4Xn2yGjvB3u6O32gtYDSAKNGgyORtEvYRbIFqjn3VBN3OZb4TN14F0Qw5+?= =?iso-8859-1?Q?SW9lCVgGkS+V4clO+3+Z69vEFqZNy9JBIFJXRstvurES8RywbCwop3YMQN?= =?iso-8859-1?Q?dIqsrq7i+5MmMqzlVeqvNWyXK+rKMORUX7G4ynMGW6zUNg0jlojbaxhPma?= =?iso-8859-1?Q?vmlHCbgDWDxyeKSbQAIqgklZeCNnGK16ESSie23YkHtINehXzoyR+vklYD?= =?iso-8859-1?Q?hHt7vDVeuKH6c/rDwFshA3lxCtTtIP8ioxbFFYijTbI8rXi0kFqY1cgFrr?= =?iso-8859-1?Q?KfxRRd4CR/o/BvSRrGjgvNEdg47j8BeHSXFxc8E7zRHLPS3DcBTC2JlaVM?= =?iso-8859-1?Q?fPetRwvK4vBMsmI4d2QWbtJoO7fkR7Gy1Qq8kYCmQQuVwIrZcMwpKsR8KX?= =?iso-8859-1?Q?CuAGir6mx9jMgq6gm7tHsee95W+6oAChC+TbnSw46Bd5Di8vT+VEEI1v8+?= =?iso-8859-1?Q?StVBWWeTPbGblxgPtwoXhgF95QbgfY6SmlKQVFf6C+95p/JC5QfSMU0qWQ?= =?iso-8859-1?Q?uaL6nrN1JifmFh2J5CpHEUB/xW53t4JABUt60k/XynWJiCpaFzSw42T3Yp?= =?iso-8859-1?Q?C2JfI9xlW3nc/6OkxqiLdK625IyZy1l3P2aJ9pU11zSSmiL6fNs4Wmd23B?= =?iso-8859-1?Q?fQ52NC4G6K6+C5BW3AZZNANAgBZT2Cr6pmREjIntX+RVapW1pH3nI8vWx0?= =?iso-8859-1?Q?pGVHWF0rFWyC7QhYvChzllZB7F7G1XT66Gk/+GksmHPDyMHBnCcAicP2+Y?= =?iso-8859-1?Q?1gmY44uPTeZoWahgDqZ2QubKAHFqDrlh7P+4HWZ/2HYGqXfTQwILXDLX6c?= =?iso-8859-1?Q?LHzfObeHTqsqG92ZR3x/zId16SD0yRovQNMqhhgJe6v/6lNkRClONo8y/s?= =?iso-8859-1?Q?zOWZVYuuIXGUnCr/WrgAHUEDH0J35hQssBsgAwiregzopN2+eBurTYQkt7?= =?iso-8859-1?Q?jbfaLBUkjPvWKiREvcqjJHF6OmFAC9CvC/7fCgGHdkeCTnjz3j61/8torh?= =?iso-8859-1?Q?CcEinYr0FvlxPhJB3oBJFKvcf/AfpWaYV46ygx/8EzvY1prfmtTMHg1phB?= =?iso-8859-1?Q?O4ShWzU98wLMNdFpfDactUEPXxesm?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1632; 5:Nn1BSEH7bTUVnhHKOzsgwsEi9EJnDuO9gaELtIrxxUqvVhT1xy/HC/0LWesb+QvDoFeU3PxBJZqddK7zLkAR9PoApcHQBf6gROopGWPcaF5S0TcSwSPeXTAyk0IgPU6NzWhDsG2w5S5dn2mC1QFEXw==; 24:jI6s0yAv4L40p3W9eRj11917wJalkHSd6fxz4HmJKdzYnBdfGztG8DCF0xk0FztjwIc9bFqcRtH5d2yRLKDh87IxvQWIMvFv5bls8p8KCwg= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Feb 2016 20:41:46.5945 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1632 Archived-At: Cc: idr , bruno.decraene@orange.com Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (4493) 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, 17 Feb 2016 20:41:59 -0000 ----- Original Message ----- From: "Jeffrey Haas" To: "Alvaro Retana (aretana)" Cc: ; Sent: Wednesday, February 17, 2016 3:19 PM Updating the registry to Unspecific would reflect common implementation practice. For years, 0 has basically meant "this doesn't fit into anything else". The existing value of reserved in the registry was likely an oversight as part of registry maintenance over the long life of BGP. Even RFC 1771 section 6 covers the 0 as an appropriate value, yet it's not listed in the enumerations of the different code types. FWIW, Junos uses the word "unspecified" in several of the debugging outputs rather than "unspecific". I would lean toward unspecified. :-) Note that the BGP MIBs do not provide any related enumerations so there is no support one way or the other in existing standardized items beyond the normative text in the RFCs that value 0 is to be used. Jeff Two more reasons to reject this Erratum First, from RFC4276 s.3.19.98. Recognized but Malformed Optional Parameters Functionality/Description: The Error Subcode MUST be set to 0 (Unspecific) RFC2119: MUST Alcatel Y/N/O/Comments: Y Cisco Y/N/O/Comments: N Laurel Y/N/O/Comments: Y NextHop Y/N/O/Comments: Y Mmmmm, shame about that 'N' Meanwhile from the archives, Date: Mon, 29 Oct 2001 12:01:24 -0500 From: Jeffrey Haas To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: draft-14 misc. comments > > : 6.2 OPEN message error handling. > > > > [...] > > > > : If one of the Optional Parameters in the OPEN message is not > > : recognized, then the Error Subcode is set to Unsupported Optional > > : Parameters. > > > > What about when optional parameters items are malformed? > > The same - Unsupported Optional Parameters. I would suggest otherwise. "Unsupported" argues that we do not support it. If it is supported and is malformed, I would argue 0 (unspecific) is more appropriate in the absence of a new error subcode. Should the draft, draft-chen-bgp-cease-subcode-00.txt, be made a generic BGP error code cleanup document if accepted as a WG item? If so, this would argue adding a new subcode to open: 7 - Malformed Optional Attribute(s) Data - contains the malformed optional attributes. In the case where the field lenghts are malformed, 0 (unspecific) is still probably appropriate. -- Jeff Haas NextHop Technologies The change was incorporated in the I-D by Yakov 31 October 2001 Tom Petch -- Jeff > On Feb 17, 2016, at 10:08 AM, Alvaro Retana (aretana) wrote: > > Idr WG: > > Please take a look at the Errata below. I need your opinion on it. > > > I'm leaning towards rejecting it because I interpret "Unspecific" not as > the name of the subcode, but as just an indication that the error is not > specific. The IANA registry [1] lists the value 0 as "Reserved", which I > think is ok according to the definition in RFC5226: > > Reserved: Not to be assigned. Reserved values are held for > special uses, such as to extend the namespace when it become > exhausted. Reserved values are not available for general > assignment. > > In this case the "special use" is when the error is not specific. > > > > Any thoughts? Other opinions? > > Thanks! > > Alvaro. > > [1] > http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp- par > ameters-4 > > > > On 10/6/15, 4:10 AM, "RFC Errata System" wrote: > >> The following errata report has been submitted for RFC4271, >> "A Border Gateway Protocol 4 (BGP-4)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=4493 >> >> -------------------------------------- >> Type: Technical >> Reported by: Bruno Decraene >> >> Section: 4.5 >> >> Original Text >> ------------- >> §\\"4.5 NOTIFICATION Message Format\\" says: >> >> Message Header Error subcodes: >> >> 1 - Connection Not Synchronized. >> 2 - Bad Message Length. >> 3 - Bad Message Type. >> >> OPEN Message Error subcodes: >> >> 1 - Unsupported Version Number. >> 2 - Bad Peer AS. >> 3 - Bad BGP Identifier. >> 4 - Unsupported Optional Parameter. >> 5 - [Deprecated - see Appendix A]. >> 6 - Unacceptable Hold Time. >> >> UPDATE Message Error subcodes: >> >> 1 - Malformed Attribute List. >> 2 - Unrecognized Well-known Attribute. >> 3 - Missing Well-known Attribute. >> 4 - Attribute Flags Error. >> 5 - Attribute Length Error. >> 6 - Invalid ORIGIN Attribute. >> 7 - [Deprecated - see Appendix A]. >> 8 - Invalid NEXT_HOP Attribute. >> 9 - Optional Attribute Error. >> 10 - Invalid Network Field. >> 11 - Malformed AS_PATH. >> >> Corrected Text >> -------------- >> Message Header Error subcodes: >> >> 0 - Unspecific. >> 1 - Connection Not Synchronized. >> 2 - Bad Message Length. >> 3 - Bad Message Type. >> >> OPEN Message Error subcodes: >> >> 0 - Unspecific. >> 1 - Unsupported Version Number. >> 2 - Bad Peer AS. >> 3 - Bad BGP Identifier. >> 4 - Unsupported Optional Parameter. >> 5 - [Deprecated - see Appendix A]. >> 6 - Unacceptable Hold Time. >> >> UPDATE Message Error subcodes: >> >> 0 - Unspecific. >> 1 - Malformed Attribute List. >> 2 - Unrecognized Well-known Attribute. >> 3 - Missing Well-known Attribute. >> 4 - Attribute Flags Error. >> 5 - Attribute Length Error. >> 6 - Invalid ORIGIN Attribute. >> 7 - [Deprecated - see Appendix A]. >> 8 - Invalid NEXT_HOP Attribute. >> 9 - Optional Attribute Error. >> 10 - Invalid Network Field. >> 11 - Malformed AS_PATH. >> >> Notes >> ----- >> RFC 4271 defines a use and a name for Error subcode 0: >> - §4.5 (any error code): >> If no appropriate Error Subcode is defined, then a zero >> (Unspecific) value is used for the Error Subcode field. >> >> - §6.2 (OPEN error code): >> If one of the Optional Parameters in the OPEN message is recognized, >> but is malformed, then the Error Subcode MUST be set to 0 >> (Unspecific). >> >> If verified, the \\"IANA Considerations\\" section and the IANA registry >> would also need to be updated accordingly (currently says \\"0 >> Reserved\\") >> http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp- pa >> rameters-4 >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4271 (draft-ietf-idr-bgp4-26) >> -------------------------------------- >> Title : A Border Gateway Protocol 4 (BGP-4) >> Publication Date : January 2006 >> Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. >> Category : DRAFT STANDARD >> Source : Inter-Domain Routing >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >> > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Wed Feb 17 13:28:41 2016 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 549EC1B2EFC for ; Wed, 17 Feb 2016 13:28:40 -0800 (PST) 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 r7HeGhHzFZRT for ; Wed, 17 Feb 2016 13:28:36 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0111.outbound.protection.outlook.com [65.55.169.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F681B2EDC for ; Wed, 17 Feb 2016 13:28:35 -0800 (PST) Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; Received: from [172.29.36.24] (66.129.241.11) by BY2PR05MB696.namprd05.prod.outlook.com (10.141.222.28) with Microsoft SMTP Server (TLS) id 15.1.403.16; Wed, 17 Feb 2016 21:28:29 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Scudder In-Reply-To: Date: Wed, 17 Feb 2016 16:28:23 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20160102183505.BC84B180094@rfc-editor.org> To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.2104) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: CY1PR15CA0001.namprd15.prod.outlook.com (25.163.14.11) To BY2PR05MB696.namprd05.prod.outlook.com (10.141.222.28) X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB696; 2:8DphmtCoy99zqMc67kFvQEi6wHhiladyYJfKVOmdt0KsvkJ7pT/oIfWA5+XOLR7/Crv47ohxFBj4qtJ2LP7Z2rBQCTMAmMYzprx08xJQKe8WzAvjccE1zH6QxXLrozde9ln49N0DfLERYazu9Xr8Mg==; 3:kGALgCuPOAqbsOnMfNUjqvQvL/YuBveXXJnUyJodNEHQJ2ZucIFFHPYAo9H5K8lJSFdVrRqZcStQZvEqb9BBvdsIsDlTq10t+WYWTm/g2CE4PeEvqV91wUI9pykk65Y6; 25:iL1MNudSEzXWZNEkY4dILmQAqStURTPbAYrSd2qjUM6AjDkykHTUM9yIqCaYuOYXQA94IFyHuE7MEMpeUoDQD9tB2snLZpsda7j0rObskZs8h8UhgQ0hPExc8IGQRMo1MVGGz2t+7P8q0Hua+eGiE31z/FMDY+J2IA14seKYtXk2xvCztvGuvozCN+vaqyr382Hcj7lJWmM1eKwI9soahwXb6dzJDFbvPEG9vVOTNuV9iKsPdKdbZweq83dev8euySl9V0qch1ODaYGvtW0uXKJFbfLDyTkKnu2tXpYJ+ry72J77q37MpdONE9wKzzL9 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB696; X-MS-Office365-Filtering-Correlation-Id: e9a8616e-1ac6-4975-0b79-08d337e147fc X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB696; 20:E/i6VweuVT0FJDlvGSMgL8G7Q+HRn4kzQbMcrVIHTvJ3Rx3xGDuA/FUqwqtWyIk/EQZjygtwu60ubpLGMixpu2FVtSpE4NvcQo6209Qf0IzARAgXUOuPlZyuxmof81OaAa6H8ITyWOlGdv/U1LrE/lZNbS/5p6TDwGo83oVR2Ev4mtRlvgXzBhkreBN0UbZG79NiaHH5jPIdU2b3M8KEA76djl18n8NPtrogiGMX+0XFaVO+6dj+kRgvSM2l5wIxtMtfXUWjSXD0XwW+mgaML9GNiENaFT56R94HeeuGEpXgcloFTtEMVEYMb+sqfJaBxl3VEvv4UGcAJke/8n+zepbDYdYApv18u18CmjRnB9Jg6TvkCiqVmdIB+Jgq1Hw7zacVpMbB7go9RceDndLkk8LarjkGeS6ybSoyra8+O2QJecxXGbsAHB1RNFCktGSmGovrM2io8fT/Ii5z2r2ztqA2UP4yv7Rntncycl+XsYhfW7FNR7Sr2KQqTEyHZl4M X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BY2PR05MB696; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB696; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB696; 4:ywwNc2lNzgj+mFxUNByjGIvX5l3vE0EDoAYhCfPCWevr1M8MMEmX8JXZ7CX8Ms8fTaxKrmDbewdpv6fIm+kVIV71AmEoMLOOKmvefa+kKT3HbY6lPmafddRG3/9PKJfcG/cX5B0/yGAtz5hyBoxO6xHOwAQ4QSVJpfHyk/x0bpKh2JxdtMunajB8xwqSbZ5EdrvdXwIPiuyGXlhFfBsPNj5L2x7EDGrL5sc2FrnbonZryJFZKV9cIE8zTeY+k0zIYV6dr3jlgekUyfJCmX5iusSato7I9mwFV+JPEvnuJTUBtPjcjNpN5hB9zzttAcTH1CtyZkgPhnNeyvl7/zcxQY8CbAedzgZm5+C2PUrULQXBzOC5jM2OR/HDN7TP8seWRfX03GCmqOHxuePKjaWW/Co3Ay1h9BJqLUjFf1E9pQm/LW7FrTpIUEqXaxw0qeBbEJBeVN0eqRxfwf3Ks72MMg== X-Forefront-PRVS: 085551F5A8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(479174004)(377454003)(24454002)(87976001)(36756003)(19580405001)(77096005)(19580395003)(110136002)(92566002)(5001960100002)(15975445007)(46406003)(50986999)(76176999)(83716003)(82746002)(1720100001)(5004730100002)(50226001)(3846002)(5008740100001)(586003)(4326007)(47776003)(2950100001)(66066001)(50466002)(23726003)(16799955002)(97756001)(42186005)(33656002)(122386002)(1096002)(189998001)(15188155005)(2906002)(6116002)(40100003)(86362001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB696; H:[172.29.36.24]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB696; 23:PXjSpZh8/nQ12vsNcjqhplxK7mBShdlj2YoKdlpy9D?= =?us-ascii?Q?/oX0QwwsV6NuMNXjy2eaChwRZSsvI6tCVDrc/7EltANRrvLyiYV+7WhbU61U?= =?us-ascii?Q?wUSQilKnew5f8xScDIS9goWEtaY7jRF0bdey1PlxNIIpdi7UNE8GRJ9SpxJ0?= =?us-ascii?Q?Dxg6NAWqd7k7gNZX0JDOFUBqouIh5Omlfst0yVLJ2uHiPwmmUYSx7o2ZHVMM?= =?us-ascii?Q?Qy6xQ0+5fOxGMAMPKJK19nvNjXVE5nkDM1BDd82vjPAlsUXjb3M5KPbI/f4m?= =?us-ascii?Q?gmulLgVam1yVAoQdaOWMzA4WKbK8BhxhYubaI8DcO318ELLsekaYH3R/bOPC?= =?us-ascii?Q?OfF9hNbagwnUiRi1Os7O5jOvO/+Z8lSN2IofDFKCLbXRh7iSp9uslJ7+NIvN?= =?us-ascii?Q?UAYnKq+zoPk1w7xUv9ua+IOaPc1VZyVswkZYJi38hUV3VQrT3fQ2LVJrgXkF?= =?us-ascii?Q?BRj4TGAp7/yAc3tzYUsxzr+VULRev7FQ2YN80lGl7l9ykOcR+k6conoIYZXT?= =?us-ascii?Q?vINWIhaFVMGO3JE3uCZcRqvmTai2fB7Z5/KyhVjhD+vbR3yVMsWYYS1bX7XL?= =?us-ascii?Q?v+AIVwWxWuplplz7kdUhHwm9HRhjMP6Do7YaLDuGPb3Iob/ChyLEMU/uZhW+?= =?us-ascii?Q?tK0UQxgu3HEau4fi3R50svGwnCOcfGP56uVg8qpaoBzSlloGOyPhjwpHARWJ?= =?us-ascii?Q?dAgvHdjI2xv5polbCag7v6ourz89j8Eg5yOi1HOvLuB+c+bXzzqPzAYFF6K6?= =?us-ascii?Q?iQpIUlKG8D7kOYsn9/SfZU0OuoPlGbZ9g1mQ6xLvARDcehbrcJMHj1GCL6A+?= =?us-ascii?Q?qsQWF3gnkQ5H+FSV0dLXb7ZymsIyMuJDtzRDJ9dMjOVvQ+kJQ1EAZ+LLuirD?= =?us-ascii?Q?/WHqosoMwNyDHtvxXSpCkc/dPazieB1q38tOIEfzzJvcyJb/887dzIR9uayF?= =?us-ascii?Q?siwiSsx1Y3BXJ/lXPXal3DFXOiSySoYM5kVPbRrLm85r7txLrKNV0kbsGYjo?= =?us-ascii?Q?pWkzlChFcoSvh+13qdIrbuSX4diiNrNHPCFhM/FCkbvE9QE/5dg28YyPsPA4?= =?us-ascii?Q?XmieyYiY4Gd/tWqc79wesmTIMJ1eFviApU9MNw8tq4yZXmoxXq1leICV2gJT?= =?us-ascii?Q?gColDcjKrXdOhYBkbyqktLOaEISwW1Xsu+yiX2W3iDzhVrULX5TAyNW+VVl5?= =?us-ascii?Q?Et78dZze+WAe03YgEpHrO+XLwRsbgE1NDv?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB696; 5:jhmslIKfBEWIaV7qG9A4C24tAA/QuwZEku4gZJl+sk2zpQIWLiyx31PjfXFpq7N3n3aqnB5nZvN+b9tLOe6Hy9zgdkezWKWy5/G+zHGCH5wrmLGJ0j1yTmpEg98o53h611mzqIOHfZt8UlYQ7gW7Fw==; 24:oLzqKM4RDxI367iFr2SHrqWWfu/ZEzhjzixPsAUaFNwsq+tmU89mE9HNle4FiSO1N+pXhONJIJMUusNqDCMB++zrKXqG6O3YYikt9NUQXf4= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Feb 2016 21:28:29.5803 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB696 Archived-At: Cc: "idr@ietf.org" , "gjoko.stamenkov@mikasta.com" Subject: Re: [Idr] [Editorial Errata Reported] RFC1997 (4576) 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, 17 Feb 2016 21:28:40 -0000 I agree with your reading (and same caveats apply). --John > On Feb 17, 2016, at 2:59 PM, Alvaro Retana (aretana) = wrote: >=20 > Idr WG: >=20 > Hi! Here's another report that I want to run through the WG. Please = see > below. >=20 > In essence, the report says that the definition of NO_EXPORT (and > NO_EXPORT_SUBCONFED) is wrong. Looking at on-line documentation I = found > this (for NO_EXPORT): >=20 > cisco: "Routes with this community are advertised to only peers in the > same autonomous system or to only other subautonomous systems within a > confederation. These routes are not advertised to external peers." [1] >=20 > Juniper: "Routes in this community must not be advertised outside a = BGP > confederation boundary." [2] >=20 > Quagga: "All routes carry this value must not be advertised to outside = a > BGP confederation boundary. If neighboring BGP peer is part of BGP > confederation, the peer is considered as inside a BGP confederation > boundary, so the route will be announced to the peer." [3] >=20 > [Sorry if I didn't look up all the vendors -- I also didn't make an = effort > to verify that the documentation says what the routers actually do.] >=20 > The descriptions above are in line with what is currently in RFC1997. >=20 >=20 > Before I reject the report (and to be on the safe side), I want to ask = the > vendors in the WG: Does the documentation really match the = functionality? > ;-) Are there implementations that don't match the functionality > described in RFC1997? >=20 > Thanks! >=20 > Alvaro. >=20 >=20 > [1]=20 > = http://www.cisco.com/c/en/us/td/docs/ios/12_2/iproute/command/reference/fi= p > rrp_r/1rfbgp1.html > [2]=20 > = http://www.juniper.net/documentation/en_US/junos13.3/topics/usage-guidelin= e > = s/policy-defining-bgp-communities-and-extended-communities-for-use-in-rout= i > ng-policy-match-conditions.html > [3]=20 > = http://www.nongnu.org/quagga/docs/docs-multi/BGP-Communities-Attribute.htm= l >=20 >=20 > On 1/2/16, 1:35 PM, "RFC Errata System" = wrote: >=20 >> The following errata report has been submitted for RFC1997, >> "BGP Communities Attribute". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D1997&eid=3D4576 >>=20 >> -------------------------------------- >> Type: Editorial >> Reported by: Gjoko Stamenkov >>=20 >> Section: GLOBAL >>=20 >> Original Text >> ------------- >> Well-known Communities >>=20 >> The following communities have global significance and their >> operations shall be implemented in any community-attribute-aware BGP >> speaker. >>=20 >> NO_EXPORT (0xFFFFFF01) >> All routes received carrying a communities attribute >> containing this value MUST NOT be advertised outside a BGP >> confederation boundary (a stand-alone autonomous system that >> is not part of a confederation should be considered a >> confederation itself). >> NO_ADVERTISE (0xFFFFFF02) >> All routes received carrying a communities attribute >> containing this value MUST NOT be advertised to other BGP >> peers. >> NO_EXPORT_SUBCONFED (0xFFFFFF03) >> All routes received carrying a communities attribute >> containing this value MUST NOT be advertised to external BGP >> peers (this includes peers in other members autonomous >> systems inside a BGP confederation). >>=20 >> Corrected Text >> -------------- >> Well-known Communities >>=20 >> The following communities have global significance and their >> operations shall be implemented in any community-attribute-aware BGP >> speaker. >>=20 >> NO_EXPORT (0xFFFFFF01) >> All routes received carrying a communities attribute >> containing this value MUST NOT be advertised to external BGP >> peers (this includes peers in other members autonomous >> systems inside a BGP confederation). >> NO_ADVERTISE (0xFFFFFF02) >> All routes received carrying a communities attribute >> containing this value MUST NOT be advertised to other BGP >> peers. >> NO_EXPORT_SUBCONFED (0xFFFFFF03) >> All routes received carrying a communities attribute >> containing this value MUST NOT be advertised outside a BGP >> confederation boundary (a stand-alone autonomous system that >> is not part of a confederation should be considered a >> confederation itself). >>=20 >> Notes >> ----- >> Definitions of NO_EXPORT and NO_EXPORT_SUBCONFED are interchanged in = the >> original text. >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >>=20 >> -------------------------------------- >> RFC1997 (no draft string recorded) >> -------------------------------------- >> Title : BGP Communities Attribute >> Publication Date : August 1996 >> Author(s) : R. Chandra, P. Traina, T. Li >> Category : PROPOSED STANDARD >> Source : Inter-Domain Routing >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >>=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Feb 17 13:42:42 2016 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 1D2881B2AB9 for ; Wed, 17 Feb 2016 13:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4asrYdhqTJtF for ; Wed, 17 Feb 2016 13:42:34 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8618A1AC40F for ; Wed, 17 Feb 2016 13:42:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12308; q=dns/txt; s=iport; t=1455745345; x=1456954945; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4pgX0wSptK0dTpXk+9u3U31Gx8nEWm2vhjatcLbYIos=; b=dlFg+N+H8xYAPDiCQR0qf0efOTZuZOzJssqpraHBfSsTQs9jxo1yYMhZ eoBNR/ov+6+0T8jHIqTpm8a6RbjqmHuaTKf8JY/hco6YnlYBSw1tr5DHm JJNHIsbkpzXmWEl50CzHXplAdviRyUuBqjaxMnbX1k8U+/Frt6BMwgr4T M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A4AgD+58RW/5hdJa1EGoM6Um0GuX4BD?= =?us-ascii?q?YFnFwyFagIcgTE4FAEBAQEBAQFkJ4RBAQEBBAEBASAROgsMBAIBCBEDAQEBAQI?= =?us-ascii?q?CJgICAiULFQgIAgQBDQUJEIgBDiysS45zAQEBAQEBAQEBAQEBAQEBAQEBAQEBF?= =?us-ascii?q?XuJUoE2gxWCaoE6BYdWCoVKgTGIKQGNWIFchEOIVIVxiFUBHgEBQoICDQyBSGo?= =?us-ascii?q?BE4cwfAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,462,1449532800"; d="scan'208";a="239747869" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2016 21:42:24 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1HLgOiI021540 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Feb 2016 21:42:24 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 17 Feb 2016 15:42:24 -0600 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Wed, 17 Feb 2016 15:42:24 -0600 From: "Acee Lindem (acee)" To: "t.petch" , Jeffrey Haas , "Alvaro Retana (aretana)" Thread-Topic: [Idr] [Technical Errata Reported] RFC4271 (4493) Thread-Index: AQHRAA6relC+roC4oE2Xudnb4lP2K58xOumAgABWuoD///Wc6YAAMlcA Date: Wed, 17 Feb 2016 21:42:24 +0000 Message-ID: References: <20151006081045.66A82187E04@rfc-editor.org> <8B1FE325-EFB5-4C5C-A4D8-1682FA3E0102@pfrc.org> <00f301d169c3$231d0a60$4001a8c0@gateway.2wire.net> In-Reply-To: <00f301d169c3$231d0a60$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.103.72] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: idr , "bruno.decraene@orange.com" Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (4493) 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, 17 Feb 2016 21:42:41 -0000 DQoNCk9uIDIvMTcvMTYsIDQ6MzggUE0sICJJZHIgb24gYmVoYWxmIG9mIHQucGV0Y2giIDxpZHIt Ym91bmNlc0BpZXRmLm9yZyBvbg0KYmVoYWxmIG9mIGlldGZjQGJ0Y29ubmVjdC5jb20+IHdyb3Rl Og0KDQo+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPkZyb206ICJKZWZmcmV5IEhhYXMi IDxqaGFhc0BwZnJjLm9yZz4NCj5UbzogIkFsdmFybyBSZXRhbmEgKGFyZXRhbmEpIiA8YXJldGFu YUBjaXNjby5jb20+DQo+Q2M6IDxpZHJAaWV0Zi5vcmc+OyA8YnJ1bm8uZGVjcmFlbmVAb3Jhbmdl LmNvbT4NCj5TZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE3LCAyMDE2IDM6MTkgUE0NCj4NCj5V cGRhdGluZyB0aGUgcmVnaXN0cnkgdG8gVW5zcGVjaWZpYyB3b3VsZCByZWZsZWN0IGNvbW1vbiBp bXBsZW1lbnRhdGlvbg0KPnByYWN0aWNlLiAgRm9yIHllYXJzLCAwIGhhcyBiYXNpY2FsbHkgbWVh bnQgInRoaXMgZG9lc24ndCBmaXQgaW50bw0KPmFueXRoaW5nIGVsc2UiLg0KPg0KPlRoZSBleGlz dGluZyB2YWx1ZSBvZiByZXNlcnZlZCBpbiB0aGUgcmVnaXN0cnkgd2FzIGxpa2VseSBhbiBvdmVy c2lnaHQNCj5hcyBwYXJ0IG9mIHJlZ2lzdHJ5IG1haW50ZW5hbmNlIG92ZXIgdGhlIGxvbmcgbGlm ZSBvZiBCR1AuICBFdmVuIFJGQw0KPjE3NzEgc2VjdGlvbiA2IGNvdmVycyB0aGUgMCBhcyBhbiBh cHByb3ByaWF0ZSB2YWx1ZSwgeWV0IGl0J3Mgbm90IGxpc3RlZA0KPmluIHRoZSBlbnVtZXJhdGlv bnMgb2YgdGhlIGRpZmZlcmVudCBjb2RlIHR5cGVzLg0KPg0KPkZXSVcsIEp1bm9zIHVzZXMgdGhl IHdvcmQgInVuc3BlY2lmaWVkIiBpbiBzZXZlcmFsIG9mIHRoZSBkZWJ1Z2dpbmcNCj5vdXRwdXRz IHJhdGhlciB0aGFuICJ1bnNwZWNpZmljIi4gIEkgd291bGQgbGVhbiB0b3dhcmQgdW5zcGVjaWZp ZWQuIDotKQ0KDQpJZiB0aGlzIGVycmF0YSBpcyBhcHByb3ZlZCAoYW5kIEkgZG9u4oCZdCBmZWVs IHN0cm9uZ2x5IGVpdGhlciB3YXkpLCBJIHdvdWxkDQp2b3RlIGVtcGhhdGljYWxseSB0byB1c2Ug 4oCcVW5zcGVjaWZpZWTigJ0uDQoNCkFjZWUgDQoNCg0KPg0KPk5vdGUgdGhhdCB0aGUgQkdQIE1J QnMgZG8gbm90IHByb3ZpZGUgYW55IHJlbGF0ZWQgZW51bWVyYXRpb25zIHNvIHRoZXJlDQo+aXMg bm8gc3VwcG9ydCBvbmUgd2F5IG9yIHRoZSBvdGhlciBpbiBleGlzdGluZyBzdGFuZGFyZGl6ZWQg aXRlbXMgYmV5b25kDQo+dGhlIG5vcm1hdGl2ZSB0ZXh0IGluIHRoZSBSRkNzIHRoYXQgdmFsdWUg MCBpcyB0byBiZSB1c2VkLg0KPg0KPjx0cD4NCj4NCj5KZWZmDQo+DQo+VHdvIG1vcmUgcmVhc29u cyB0byByZWplY3QgdGhpcyBFcnJhdHVtDQo+DQo+Rmlyc3QsIGZyb20gUkZDNDI3Ng0KPg0KPnMu My4xOS45OC4gIFJlY29nbml6ZWQgYnV0IE1hbGZvcm1lZCBPcHRpb25hbCBQYXJhbWV0ZXJzDQo+ DQo+ICAgICAgIEZ1bmN0aW9uYWxpdHkvRGVzY3JpcHRpb246IFRoZSBFcnJvciBTdWJjb2RlIE1V U1QgYmUgc2V0IHRvIDANCj4gICAgICAgKFVuc3BlY2lmaWMpDQo+DQo+ICAgICAgIFJGQzIxMTk6 IE1VU1QNCj4NCj4gICAgICAgQWxjYXRlbCBZL04vTy9Db21tZW50czogWQ0KPiAgICAgICBDaXNj byAgIFkvTi9PL0NvbW1lbnRzOiBODQo+ICAgICAgIExhdXJlbCAgWS9OL08vQ29tbWVudHM6IFkN Cj4gICAgICAgTmV4dEhvcCBZL04vTy9Db21tZW50czogWQ0KPg0KPk1tbW1tLCBzaGFtZSBhYm91 dCB0aGF0ICdOJw0KPg0KPk1lYW53aGlsZSBmcm9tIHRoZSBhcmNoaXZlcywNCj4NCj5EYXRlOiBN b24sIDI5IE9jdCAyMDAxIDEyOjAxOjI0IC0wNTAwDQo+RnJvbTogSmVmZnJleSBIYWFzIDxqaGFh c0BuZXh0aG9wLmNvbT4NCj5UbzogWWFrb3YgUmVraHRlciA8eWFrb3ZAanVuaXBlci5uZXQ+DQo+ Q2M6IGlkckBtZXJpdC5lZHUNCj5TdWJqZWN0OiBSZTogZHJhZnQtMTQgbWlzYy4gY29tbWVudHMN Cj48c25pcD4NCj4NCj4+ID4gOiA2LjIgT1BFTiBtZXNzYWdlIGVycm9yIGhhbmRsaW5nLg0KPj4g Pg0KPj4gPiBbLi4uXQ0KPj4gPg0KPj4gPiA6ICAgIElmIG9uZSBvZiB0aGUgT3B0aW9uYWwgUGFy YW1ldGVycyBpbiB0aGUgT1BFTiBtZXNzYWdlIGlzIG5vdA0KPj4gPiA6ICAgIHJlY29nbml6ZWQs IHRoZW4gdGhlIEVycm9yIFN1YmNvZGUgaXMgc2V0IHRvIFVuc3VwcG9ydGVkDQo+T3B0aW9uYWwN Cj4+ID4gOiAgICBQYXJhbWV0ZXJzLg0KPj4gPg0KPj4gPiBXaGF0IGFib3V0IHdoZW4gb3B0aW9u YWwgcGFyYW1ldGVycyBpdGVtcyBhcmUgbWFsZm9ybWVkPw0KPj4NCj4+IFRoZSBzYW1lIC0gVW5z dXBwb3J0ZWQgT3B0aW9uYWwgUGFyYW1ldGVycy4NCj4NCj5JIHdvdWxkIHN1Z2dlc3Qgb3RoZXJ3 aXNlLiAgIlVuc3VwcG9ydGVkIiBhcmd1ZXMgdGhhdCB3ZSBkbyBub3Qgc3VwcG9ydA0KPml0LiAg SWYgaXQgaXMgc3VwcG9ydGVkIGFuZCBpcyBtYWxmb3JtZWQsIEkgd291bGQgYXJndWUgMCAodW5z cGVjaWZpYykNCj5pcyBtb3JlIGFwcHJvcHJpYXRlIGluIHRoZSBhYnNlbmNlIG9mIGEgbmV3IGVy cm9yIHN1YmNvZGUuDQo+DQo+U2hvdWxkIHRoZSBkcmFmdCwgZHJhZnQtY2hlbi1iZ3AtY2Vhc2Ut c3ViY29kZS0wMC50eHQsIGJlIG1hZGUgYQ0KPmdlbmVyaWMgQkdQIGVycm9yIGNvZGUgY2xlYW51 cCBkb2N1bWVudCBpZiBhY2NlcHRlZCBhcyBhIFdHIGl0ZW0/DQo+DQo+SWYgc28sIHRoaXMgd291 bGQgYXJndWUgYWRkaW5nIGEgbmV3IHN1YmNvZGUgdG8gb3BlbjoNCj4NCj43IC0gTWFsZm9ybWVk IE9wdGlvbmFsIEF0dHJpYnV0ZShzKQ0KPkRhdGEgLSBjb250YWlucyB0aGUgbWFsZm9ybWVkIG9w dGlvbmFsIGF0dHJpYnV0ZXMuDQo+DQo+SW4gdGhlIGNhc2Ugd2hlcmUgdGhlIGZpZWxkIGxlbmdo dHMgYXJlIG1hbGZvcm1lZCwgMCAodW5zcGVjaWZpYykgaXMNCj5zdGlsbCBwcm9iYWJseSBhcHBy b3ByaWF0ZS4NCj4NCj4tLQ0KPkplZmYgSGFhcw0KPk5leHRIb3AgVGVjaG5vbG9naWVzDQo+DQo+ PGVuZCBvZiBleHRyYWN0IGZyb20gdGhlIGFyY2hpdmVzPg0KPg0KPlRoZSBjaGFuZ2Ugd2FzIGlu Y29ycG9yYXRlZCBpbiB0aGUgSS1EIGJ5IFlha292IDMxIE9jdG9iZXIgMjAwMQ0KPg0KPlRvbSBQ ZXRjaA0KPg0KPi0tIEplZmYNCj4NCj4NCj4+IE9uIEZlYiAxNywgMjAxNiwgYXQgMTA6MDggQU0s IEFsdmFybyBSZXRhbmEgKGFyZXRhbmEpDQo+PGFyZXRhbmFAY2lzY28uY29tPiB3cm90ZToNCj4+ DQo+PiBJZHIgV0c6DQo+Pg0KPj4gUGxlYXNlIHRha2UgYSBsb29rIGF0IHRoZSBFcnJhdGEgYmVs b3cuICBJIG5lZWQgeW91ciBvcGluaW9uIG9uIGl0Lg0KPj4NCj4+DQo+PiBJJ20gbGVhbmluZyB0 b3dhcmRzIHJlamVjdGluZyBpdCBiZWNhdXNlIEkgaW50ZXJwcmV0ICJVbnNwZWNpZmljIiBub3QN Cj5hcw0KPj4gdGhlIG5hbWUgb2YgdGhlIHN1YmNvZGUsIGJ1dCBhcyBqdXN0IGFuIGluZGljYXRp b24gdGhhdCB0aGUgZXJyb3IgaXMNCj5ub3QNCj4+IHNwZWNpZmljLiAgVGhlIElBTkEgcmVnaXN0 cnkgWzFdIGxpc3RzIHRoZSB2YWx1ZSAwIGFzICJSZXNlcnZlZCIsDQo+d2hpY2ggSQ0KPj4gdGhp bmsgaXMgb2sgYWNjb3JkaW5nIHRvIHRoZSBkZWZpbml0aW9uIGluIFJGQzUyMjY6DQo+Pg0KPj4g ICAgICBSZXNlcnZlZDogIE5vdCB0byBiZSBhc3NpZ25lZC4gIFJlc2VydmVkIHZhbHVlcyBhcmUg aGVsZCBmb3INCj4+ICAgICAgICAgICAgc3BlY2lhbCB1c2VzLCBzdWNoIGFzIHRvIGV4dGVuZCB0 aGUgbmFtZXNwYWNlIHdoZW4gaXQNCj5iZWNvbWUNCj4+ICAgICAgICAgICAgZXhoYXVzdGVkLiAg UmVzZXJ2ZWQgdmFsdWVzIGFyZSBub3QgYXZhaWxhYmxlIGZvciBnZW5lcmFsDQo+PiAgICAgICAg ICAgIGFzc2lnbm1lbnQuDQo+Pg0KPj4gSW4gdGhpcyBjYXNlIHRoZSAic3BlY2lhbCB1c2UiIGlz IHdoZW4gdGhlIGVycm9yIGlzIG5vdCBzcGVjaWZpYy4NCj4+DQo+Pg0KPj4NCj4+IEFueSB0aG91 Z2h0cz8gIE90aGVyIG9waW5pb25zPw0KPj4NCj4+IFRoYW5rcyENCj4+DQo+PiBBbHZhcm8uDQo+ Pg0KPj4gWzFdDQo+Pg0KPmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvYmdwLXBhcmFt ZXRlcnMvYmdwLXBhcmFtZXRlcnMueGh0bWwjYmdwLQ0KPnBhcg0KPj4gYW1ldGVycy00DQo+Pg0K Pj4NCj4+DQo+PiBPbiAxMC82LzE1LCA0OjEwIEFNLCAiUkZDIEVycmF0YSBTeXN0ZW0iIDxyZmMt ZWRpdG9yQHJmYy1lZGl0b3Iub3JnPg0KPndyb3RlOg0KPj4NCj4+PiBUaGUgZm9sbG93aW5nIGVy cmF0YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVkIGZvciBSRkM0MjcxLA0KPj4+ICJBIEJvcmRl ciBHYXRld2F5IFByb3RvY29sIDQgKEJHUC00KSIuDQo+Pj4NCj4+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IFlvdSBtYXkgcmV2aWV3IHRoZSByZXBvcnQgYmVs b3cgYW5kIGF0Og0KPj4+IGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5w aHA/cmZjPTQyNzEmZWlkPTQ0OTMNCj4+Pg0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+Pj4gVHlwZTogVGVjaG5pY2FsDQo+Pj4gUmVwb3J0ZWQgYnk6IEJydW5v IERlY3JhZW5lIDxicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPg0KPj4+DQo+Pj4gU2VjdGlvbjog NC41DQo+Pj4NCj4+PiBPcmlnaW5hbCBUZXh0DQo+Pj4gLS0tLS0tLS0tLS0tLQ0KPj4+IMKnXFwi NC41IE5PVElGSUNBVElPTiBNZXNzYWdlIEZvcm1hdFxcIiBzYXlzOg0KPj4+DQo+Pj4gICAgIE1l c3NhZ2UgSGVhZGVyIEVycm9yIHN1YmNvZGVzOg0KPj4+DQo+Pj4gICAgICAgICAgICAgIDEgLSBD b25uZWN0aW9uIE5vdCBTeW5jaHJvbml6ZWQuDQo+Pj4gICAgICAgICAgICAgIDIgLSBCYWQgTWVz c2FnZSBMZW5ndGguDQo+Pj4gICAgICAgICAgICAgIDMgLSBCYWQgTWVzc2FnZSBUeXBlLg0KPj4+ DQo+Pj4gICAgIE9QRU4gTWVzc2FnZSBFcnJvciBzdWJjb2RlczoNCj4+Pg0KPj4+ICAgICAgICAg ICAgICAxIC0gVW5zdXBwb3J0ZWQgVmVyc2lvbiBOdW1iZXIuDQo+Pj4gICAgICAgICAgICAgIDIg LSBCYWQgUGVlciBBUy4NCj4+PiAgICAgICAgICAgICAgMyAtIEJhZCBCR1AgSWRlbnRpZmllci4N Cj4+PiAgICAgICAgICAgICAgNCAtIFVuc3VwcG9ydGVkIE9wdGlvbmFsIFBhcmFtZXRlci4NCj4+ PiAgICAgICAgICAgICAgNSAtIFtEZXByZWNhdGVkIC0gc2VlIEFwcGVuZGl4IEFdLg0KPj4+ICAg ICAgICAgICAgICA2IC0gVW5hY2NlcHRhYmxlIEhvbGQgVGltZS4NCj4+Pg0KPj4+ICAgICBVUERB VEUgTWVzc2FnZSBFcnJvciBzdWJjb2RlczoNCj4+Pg0KPj4+ICAgICAgICAgICAgICAxIC0gTWFs Zm9ybWVkIEF0dHJpYnV0ZSBMaXN0Lg0KPj4+ICAgICAgICAgICAgICAyIC0gVW5yZWNvZ25pemVk IFdlbGwta25vd24gQXR0cmlidXRlLg0KPj4+ICAgICAgICAgICAgICAzIC0gTWlzc2luZyBXZWxs LWtub3duIEF0dHJpYnV0ZS4NCj4+PiAgICAgICAgICAgICAgNCAtIEF0dHJpYnV0ZSBGbGFncyBF cnJvci4NCj4+PiAgICAgICAgICAgICAgNSAtIEF0dHJpYnV0ZSBMZW5ndGggRXJyb3IuDQo+Pj4g ICAgICAgICAgICAgIDYgLSBJbnZhbGlkIE9SSUdJTiBBdHRyaWJ1dGUuDQo+Pj4gICAgICAgICAg ICAgIDcgLSBbRGVwcmVjYXRlZCAtIHNlZSBBcHBlbmRpeCBBXS4NCj4+PiAgICAgICAgICAgICAg OCAtIEludmFsaWQgTkVYVF9IT1AgQXR0cmlidXRlLg0KPj4+ICAgICAgICAgICAgICA5IC0gT3B0 aW9uYWwgQXR0cmlidXRlIEVycm9yLg0KPj4+ICAgICAgICAgICAgIDEwIC0gSW52YWxpZCBOZXR3 b3JrIEZpZWxkLg0KPj4+ICAgICAgICAgICAgIDExIC0gTWFsZm9ybWVkIEFTX1BBVEguDQo+Pj4N Cj4+PiBDb3JyZWN0ZWQgVGV4dA0KPj4+IC0tLS0tLS0tLS0tLS0tDQo+Pj4gICAgIE1lc3NhZ2Ug SGVhZGVyIEVycm9yIHN1YmNvZGVzOg0KPj4+DQo+Pj4gICAgICAgICAgICAgIDAgLSBVbnNwZWNp ZmljLg0KPj4+ICAgICAgICAgICAgICAxIC0gQ29ubmVjdGlvbiBOb3QgU3luY2hyb25pemVkLg0K Pj4+ICAgICAgICAgICAgICAyIC0gQmFkIE1lc3NhZ2UgTGVuZ3RoLg0KPj4+ICAgICAgICAgICAg ICAzIC0gQmFkIE1lc3NhZ2UgVHlwZS4NCj4+Pg0KPj4+ICAgICBPUEVOIE1lc3NhZ2UgRXJyb3Ig c3ViY29kZXM6DQo+Pj4NCj4+PiAgICAgICAgICAgICAgMCAtIFVuc3BlY2lmaWMuDQo+Pj4gICAg ICAgICAgICAgIDEgLSBVbnN1cHBvcnRlZCBWZXJzaW9uIE51bWJlci4NCj4+PiAgICAgICAgICAg ICAgMiAtIEJhZCBQZWVyIEFTLg0KPj4+ICAgICAgICAgICAgICAzIC0gQmFkIEJHUCBJZGVudGlm aWVyLg0KPj4+ICAgICAgICAgICAgICA0IC0gVW5zdXBwb3J0ZWQgT3B0aW9uYWwgUGFyYW1ldGVy Lg0KPj4+ICAgICAgICAgICAgICA1IC0gW0RlcHJlY2F0ZWQgLSBzZWUgQXBwZW5kaXggQV0uDQo+ Pj4gICAgICAgICAgICAgIDYgLSBVbmFjY2VwdGFibGUgSG9sZCBUaW1lLg0KPj4+DQo+Pj4gICAg IFVQREFURSBNZXNzYWdlIEVycm9yIHN1YmNvZGVzOg0KPj4+DQo+Pj4gICAgICAgICAgICAgIDAg LSBVbnNwZWNpZmljLg0KPj4+ICAgICAgICAgICAgICAxIC0gTWFsZm9ybWVkIEF0dHJpYnV0ZSBM aXN0Lg0KPj4+ICAgICAgICAgICAgICAyIC0gVW5yZWNvZ25pemVkIFdlbGwta25vd24gQXR0cmli dXRlLg0KPj4+ICAgICAgICAgICAgICAzIC0gTWlzc2luZyBXZWxsLWtub3duIEF0dHJpYnV0ZS4N Cj4+PiAgICAgICAgICAgICAgNCAtIEF0dHJpYnV0ZSBGbGFncyBFcnJvci4NCj4+PiAgICAgICAg ICAgICAgNSAtIEF0dHJpYnV0ZSBMZW5ndGggRXJyb3IuDQo+Pj4gICAgICAgICAgICAgIDYgLSBJ bnZhbGlkIE9SSUdJTiBBdHRyaWJ1dGUuDQo+Pj4gICAgICAgICAgICAgIDcgLSBbRGVwcmVjYXRl ZCAtIHNlZSBBcHBlbmRpeCBBXS4NCj4+PiAgICAgICAgICAgICAgOCAtIEludmFsaWQgTkVYVF9I T1AgQXR0cmlidXRlLg0KPj4+ICAgICAgICAgICAgICA5IC0gT3B0aW9uYWwgQXR0cmlidXRlIEVy cm9yLg0KPj4+ICAgICAgICAgICAgIDEwIC0gSW52YWxpZCBOZXR3b3JrIEZpZWxkLg0KPj4+ICAg ICAgICAgICAgIDExIC0gTWFsZm9ybWVkIEFTX1BBVEguDQo+Pj4NCj4+PiBOb3Rlcw0KPj4+IC0t LS0tDQo+Pj4gUkZDIDQyNzEgZGVmaW5lcyBhIHVzZSBhbmQgYSBuYW1lIGZvciBFcnJvciBzdWJj b2RlIDA6DQo+Pj4gLSDCpzQuNSAoYW55IGVycm9yIGNvZGUpOg0KPj4+ICAgICAgICBJZiBubyBh cHByb3ByaWF0ZSBFcnJvciBTdWJjb2RlIGlzIGRlZmluZWQsIHRoZW4gYSB6ZXJvDQo+Pj4gICAg ICAgIChVbnNwZWNpZmljKSB2YWx1ZSBpcyB1c2VkIGZvciB0aGUgRXJyb3IgU3ViY29kZSBmaWVs ZC4NCj4+Pg0KPj4+IC0gwqc2LjIgKE9QRU4gZXJyb3IgY29kZSk6DQo+Pj4gIElmIG9uZSBvZiB0 aGUgT3B0aW9uYWwgUGFyYW1ldGVycyBpbiB0aGUgT1BFTiBtZXNzYWdlIGlzIHJlY29nbml6ZWQs DQo+Pj4gIGJ1dCBpcyBtYWxmb3JtZWQsIHRoZW4gdGhlIEVycm9yIFN1YmNvZGUgTVVTVCBiZSBz ZXQgdG8gMA0KPj4+ICAoVW5zcGVjaWZpYykuDQo+Pj4NCj4+PiBJZiB2ZXJpZmllZCwgdGhlIFxc IklBTkEgQ29uc2lkZXJhdGlvbnNcXCIgc2VjdGlvbiBhbmQgdGhlIElBTkENCj5yZWdpc3RyeQ0K Pj4+IHdvdWxkIGFsc28gbmVlZCB0byBiZSB1cGRhdGVkIGFjY29yZGluZ2x5IChjdXJyZW50bHkg c2F5cyBcXCIwDQo+Pj4gUmVzZXJ2ZWRcXCIpDQo+Pj4NCj5odHRwOi8vd3d3LmlhbmEub3JnL2Fz c2lnbm1lbnRzL2JncC1wYXJhbWV0ZXJzL2JncC1wYXJhbWV0ZXJzLnhodG1sI2JncC0NCj5wYQ0K Pj4+IHJhbWV0ZXJzLTQNCj4+Pg0KPj4+IEluc3RydWN0aW9uczoNCj4+PiAtLS0tLS0tLS0tLS0t DQo+Pj4gVGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgIlJlcG9ydGVkIi4gSWYg bmVjZXNzYXJ5LCBwbGVhc2UNCj4+PiB1c2UgIlJlcGx5IEFsbCIgdG8gZGlzY3VzcyB3aGV0aGVy IGl0IHNob3VsZCBiZSB2ZXJpZmllZCBvcg0KPj4+IHJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24g aXMgcmVhY2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0eSAoSUVTRykNCj4+PiBjYW4gbG9nIGluIHRv IGNoYW5nZSB0aGUgc3RhdHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5lY2Vzc2FyeS4NCj4+ Pg0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gUkZDNDI3 MSAoZHJhZnQtaWV0Zi1pZHItYmdwNC0yNikNCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPj4+IFRpdGxlICAgICAgICAgICAgICAgOiBBIEJvcmRlciBHYXRld2F5 IFByb3RvY29sIDQgKEJHUC00KQ0KPj4+IFB1YmxpY2F0aW9uIERhdGUgICAgOiBKYW51YXJ5IDIw MDYNCj4+PiBBdXRob3IocykgICAgICAgICAgIDogWS4gUmVraHRlciwgRWQuLCBULiBMaSwgRWQu LCBTLiBIYXJlcywgRWQuDQo+Pj4gQ2F0ZWdvcnkgICAgICAgICAgICA6IERSQUZUIFNUQU5EQVJE DQo+Pj4gU291cmNlICAgICAgICAgICAgICA6IEludGVyLURvbWFpbiBSb3V0aW5nDQo+Pj4gQXJl YSAgICAgICAgICAgICAgICA6IFJvdXRpbmcNCj4+PiBTdHJlYW0gICAgICAgICAgICAgIDogSUVU Rg0KPj4+IFZlcmlmeWluZyBQYXJ0eSAgICAgOiBJRVNHDQo+Pj4NCj4+DQo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gSWRyIG1haWxpbmcgbGlz dA0KPj4gSWRyQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkcg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+SWRyIG1haWxpbmcgbGlzdA0KPklkckBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj5JZHIgbWFpbGluZyBsaXN0DQo+SWRyQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg0K From nobody Thu Feb 18 01:08:32 2016 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 2147B1B3BC1 for ; Thu, 18 Feb 2016 01:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.305 X-Spam-Level: X-Spam-Status: No, score=-1.305 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 oUf7KfTok12x for ; Thu, 18 Feb 2016 01:08:29 -0800 (PST) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C2C1B3B59 for ; Thu, 18 Feb 2016 01:08:29 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 7CDE240323; Thu, 18 Feb 2016 10:08:27 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 50C591A0061; Thu, 18 Feb 2016 10:08:27 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0279.002; Thu, 18 Feb 2016 10:08:26 +0100 From: To: t.petch , "Alvaro Retana (aretana)" , "idr@ietf.org" Thread-Topic: [Idr] [Technical Errata Reported] RFC4271 (4493) Thread-Index: AQHRaadK/hYhwGCkOEatlX/fHEzJa58xgayw Date: Thu, 18 Feb 2016 09:08:26 +0000 Message-ID: <6928_1455786507_56C58A0B_6928_729_1_53C29892C857584299CBF5D05346208A0F7CE538@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <20151006081045.66A82187E04@rfc-editor.org> <008901d169a6$cc3d1da0$4001a8c0@gateway.2wire.net> In-Reply-To: <008901d169a6$cc3d1da0$4001a8c0@gateway.2wire.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (4493) 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, 18 Feb 2016 09:08:31 -0000 Hi Tom, Please see inline > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Wednesday, February 17= , 2016 6:15 PM >=20 > ----- Original Message ----- > From: "Alvaro Retana (aretana)" > To: > Cc: > Sent: Wednesday, February 17, 2016 3:08 PM >=20 > Idr WG: >=20 > Please take a look at the Errata below. I need your opinion on it. >=20 > I'm leaning towards rejecting it because I interpret "Unspecific" not as > the name of the subcode, but as just an indication that the error is not > specific. The IANA registry [1] lists the value 0 as "Reserved", which > I > think is ok according to the definition in RFC5226: >=20 > >=20 > Reject. >=20 > s.6.2 specifies a specific(!) instance of using 0(Unspecific) (so I > think that IANA is in error here). Arguably, you could raise an erratum > to add 0(Unspecific) for the OPEN Message Error subcodes list=20 Agreed. > but I > think that it would be a technical change to add it for the other > messages. As currently defined, it could be seen as an implementation > error were subcode 0 be used for the other messages (an interpretation > which I have no problem with). I don't think you can call "implementation error" a behavior which is speci= fied in the RFC: "If no appropriate Error Subcode is defined, then a zero (Unspecific) value= is used for the Error Subcode field." https://tools.ietf.org/html/rfc4271#section-4.5 This sentence is generic and applies to all error codes. Accepting the errata or not is a different story. -- Bruno > If there are errors that cannot be reported using the subcodes in > RC4271, then that is a separate issue that could be worth investigating. >=20 > Tom Petch >=20 >=20 > Reserved: Not to be assigned. Reserved values are held for > special uses, such as to extend the namespace when it become > exhausted. Reserved values are not available for general > assignment. >=20 > In this case the "special use" is when the error is not specific. >=20 > Any thoughts? Other opinions? >=20 > Thanks! >=20 > Alvaro. >=20 > [1] > http://www.iana.org/assignments/bgp-parameters/bgp- > parameters.xhtml#bgp- > par > ameters-4 >=20 > On 10/6/15, 4:10 AM, "RFC Errata System" > wrote: >=20 > >The following errata report has been submitted for RFC4271, > >"A Border Gateway Protocol 4 (BGP-4)". > > > >-------------------------------------- > >You may review the report below and at: > >http://www.rfc-editor.org/errata_search.php?rfc=3D4271&eid=3D4493 > > > >-------------------------------------- > >Type: Technical > >Reported by: Bruno Decraene > > > >Section: 4.5 > > > >Original Text > >------------- > >=A7\\"4.5 NOTIFICATION Message Format\\" says: > > > > Message Header Error subcodes: > > > > 1 - Connection Not Synchronized. > > 2 - Bad Message Length. > > 3 - Bad Message Type. > > > > OPEN Message Error subcodes: > > > > 1 - Unsupported Version Number. > > 2 - Bad Peer AS. > > 3 - Bad BGP Identifier. > > 4 - Unsupported Optional Parameter. > > 5 - [Deprecated - see Appendix A]. > > 6 - Unacceptable Hold Time. > > > > UPDATE Message Error subcodes: > > > > 1 - Malformed Attribute List. > > 2 - Unrecognized Well-known Attribute. > > 3 - Missing Well-known Attribute. > > 4 - Attribute Flags Error. > > 5 - Attribute Length Error. > > 6 - Invalid ORIGIN Attribute. > > 7 - [Deprecated - see Appendix A]. > > 8 - Invalid NEXT_HOP Attribute. > > 9 - Optional Attribute Error. > > 10 - Invalid Network Field. > > 11 - Malformed AS_PATH. > > > >Corrected Text > >-------------- > > Message Header Error subcodes: > > > > 0 - Unspecific. > > 1 - Connection Not Synchronized. > > 2 - Bad Message Length. > > 3 - Bad Message Type. > > > > OPEN Message Error subcodes: > > > > 0 - Unspecific. > > 1 - Unsupported Version Number. > > 2 - Bad Peer AS. > > 3 - Bad BGP Identifier. > > 4 - Unsupported Optional Parameter. > > 5 - [Deprecated - see Appendix A]. > > 6 - Unacceptable Hold Time. > > > > UPDATE Message Error subcodes: > > > > 0 - Unspecific. > > 1 - Malformed Attribute List. > > 2 - Unrecognized Well-known Attribute. > > 3 - Missing Well-known Attribute. > > 4 - Attribute Flags Error. > > 5 - Attribute Length Error. > > 6 - Invalid ORIGIN Attribute. > > 7 - [Deprecated - see Appendix A]. > > 8 - Invalid NEXT_HOP Attribute. > > 9 - Optional Attribute Error. > > 10 - Invalid Network Field. > > 11 - Malformed AS_PATH. > > > >Notes > >----- > >RFC 4271 defines a use and a name for Error subcode 0: > >- =A74.5 (any error code): > > If no appropriate Error Subcode is defined, then a zero > > (Unspecific) value is used for the Error Subcode field. > > > >- =A76.2 (OPEN error code): > > If one of the Optional Parameters in the OPEN message is recognized, > > but is malformed, then the Error Subcode MUST be set to 0 > > (Unspecific). > > > >If verified, the \\"IANA Considerations\\" section and the IANA > registry > >would also need to be updated accordingly (currently says \\"0 > >Reserved\\") > >http://www.iana.org/assignments/bgp-parameters/bgp- > parameters.xhtml#bgp > -pa > >rameters-4 > > > >Instructions: > >------------- > >This erratum is currently posted as "Reported". If necessary, please > >use "Reply All" to discuss whether it should be verified or > >rejected. When a decision is reached, the verifying party (IESG) > >can log in to change the status and edit the report, if necessary. > > > >-------------------------------------- > >RFC4271 (draft-ietf-idr-bgp4-26) > >-------------------------------------- > >Title : A Border Gateway Protocol 4 (BGP-4) > >Publication Date : January 2006 > >Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. > >Category : DRAFT STANDARD > >Source : Inter-Domain Routing > >Area : Routing > >Stream : IETF > >Verifying Party : IESG > > >=20 > _______________________________________________ > 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 Mon Feb 22 12:31:41 2016 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 F19A41A1B86 for ; Mon, 22 Feb 2016 12:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 LFZYH_sCchXt for ; Mon, 22 Feb 2016 12:31:37 -0800 (PST) Received: from atl4mhob18.myregisteredsite.com (atl4mhob18.myregisteredsite.com [209.17.115.111]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE171A1ABC for ; Mon, 22 Feb 2016 12:31:37 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob18.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u1MKVaNb023018 for ; Mon, 22 Feb 2016 15:31:36 -0500 Received: (qmail 14094 invoked by uid 0); 22 Feb 2016 20:31:35 -0000 X-TCPREMOTEIP: 65.189.201.79 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.104?) (wes@mti-systems.com@65.189.201.79) by 0 with ESMTPA; 22 Feb 2016 20:31:35 -0000 To: Linda Dunbar , Justin Dailey , "idr@ietf.org" References: <4A95BA014132FF49AE685FAB4B9F17F657DEA4A3@dfweml701-chm> From: Wesley Eddy Message-ID: <56CB701F.5010500@mti-systems.com> Date: Mon, 22 Feb 2016 15:31:27 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657DEA4A3@dfweml701-chm> Content-Type: multipart/alternative; boundary="------------000709040303080600050507" Archived-At: Subject: Re: [Idr] questions to draft-eddy-idr-flowspec-exp-00 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, 22 Feb 2016 20:31:40 -0000 This is a multi-part message in MIME format. --------------000709040303080600050507 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Linda, thanks for the feedback, here are some answers inline: On 2/10/2016 9:33 PM, Linda Dunbar wrote: > > Wes, et al, > > I have some questions to your draft-eddy-idr-flowspec-exp-00: > > 2.1. Packet Rate Action: > > Is the “packet rate” described here intended for “matching condition”? > (same way as the matching types proposed by RFC5575? > No, it is intended as an action applied to traffic matching the filter. In flowspec/5575, the community attributes are used to indicate the action, whereas the NLRI indicates the matching criteria. > 2.2. Tunnel Description: > > - To match a flow with specific outer tunnel and inner TCP or UDP, > “logical operators (AND, OR, NOR)” should be enough. Why need to > specifically state “tunnel”? > > -The“Offset-Value-Mask” matching is not intended to be propagated to > other peers , is it? > Yes, if not propagated to other peers, it wouldn't be useful to include in BGP :) > -Page 7 last sentence: what does “A” mean in “to address A within a > GRE flow to address Pout …”? > That was just intended as a variable "A". It could have been any other symbol. > 3. Other discussion: > > You stated that RFC5575 can be translated easily to ACL. The Matching > & Action can. But ACL is local to the node, which are not propagated > to peers as specified by RFC5575. > Agreed. > For the Anti-DDoS use case, Controller may only wants to impose the > ACL for a specific node, instead of sending a big wave to all the ASs. > Other ASs may have its own Anti-DDoC controller temporarily steering > some suspicious traffic to its own security scrubbing center. > Propagating Anti-DDoS steering policies to other ASs can make the > large network oscillate violently (& unnecessarily) . > The logic for controlling distribution of updates is a separate problem, and actually more difficult than just defining a wire format. You are definitely correct that this logic and the configuration settings in practice are very important to successfully deploying something like this. That logic doesn't really need to be standardized IMO, though, since it can be different in various ASes or products, as long as they can communicate over the wire. > To contain the unnecessary complexity, there should be two types of > Flow Spec control: > > -Distributed, i.e. flowSpec coming from (or propagated to) peers. > > -Centralized, i.e. “Flow Specs” coming from its designated “controller”. > > Under the “Centralized” mode, there should be a mode that doesn’t > propagate received route policies to peers (i.e. localized policy). > Under this “Centralized & no propagating” mode, a lot of tricky > issues (like security) goes away. > That would be one possible implementation approach, IMO, though there may be others, for instance with subsets of rules to redistribute indicated in policies on a neighbor-by-neighbor basis. --------------000709040303080600050507 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Linda, thanks for the feedback, here are some answers inline:

On 2/10/2016 9:33 PM, Linda Dunbar wrote:

Wes, et al,

 

I have some questions to your draft-eddy-idr-flowspec-exp-00:

 

2.1. Packet Rate Action:

 

Is the “packet rate” described here intended for “matching condition”? (same way as the matching types proposed by RFC5575?



No, it is intended as an action applied to traffic matching the filter.  In flowspec/5575, the community attributes are used to indicate the action, whereas the NLRI indicates the matching criteria.


 

2.2. Tunnel Description:

-  To match a flow with specific outer tunnel and inner TCP or UDP, “logical operators (AND, OR, NOR)” should be enough. Why need to specifically state “tunnel”?

 

-        The “Offset-Value-Mask” matching is not intended to be propagated to other peers , is it?


Yes, if not propagated to other peers, it wouldn't be useful to include in BGP :)

-        Page 7 last sentence: what does “A” mean in “to address A within a GRE flow to address Pout …”?

 


That was just intended as a variable "A".  It could have been any other symbol.


 

3. Other discussion:

 

You stated that RFC5575 can be translated easily to ACL. The Matching & Action can. But ACL is local to the node, which are not propagated to peers as specified by RFC5575.


Agreed.


 

For the Anti-DDoS use case, Controller may only wants to impose the ACL for a specific node, instead of sending a big wave to all the ASs.  Other ASs may have its own Anti-DDoC controller temporarily steering some suspicious traffic to its own security scrubbing center. Propagating Anti-DDoS steering policies to other ASs can make the large network oscillate violently (& unnecessarily) .


The logic for controlling distribution of updates is a separate problem, and actually more difficult than just defining a wire format.  You are definitely correct that this logic and the configuration settings in practice are very important to successfully deploying something like this.  That logic doesn't really need to be standardized IMO, though, since it can be different in various ASes or products, as long as they can communicate over the wire.


To contain the unnecessary complexity, there should be two types of Flow Spec control:

-        Distributed, i.e. flowSpec coming from (or propagated to) peers.

-        Centralized, i.e. “Flow Specs” coming from its designated “controller”.

 

Under the “Centralized” mode, there should be a mode that doesn’t propagate received route policies to peers (i.e. localized policy).  Under this “Centralized & no propagating” mode, a lot of tricky issues (like security) goes away.

 


That would be one possible implementation approach, IMO, though there may be others, for instance with subsets of rules to redistribute indicated in policies on a neighbor-by-neighbor basis.


--------------000709040303080600050507-- From nobody Mon Feb 22 14:06:43 2016 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 6B4C21AD0CB for ; Mon, 22 Feb 2016 14:06:41 -0800 (PST) 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 GNyxnLv3K163 for ; Mon, 22 Feb 2016 14:06:36 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0780.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:780]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3BB1AD062 for ; Mon, 22 Feb 2016 14:06:36 -0800 (PST) Authentication-Results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=juniper.net; Received: from thuongn-sslvpn-nc.jnpr.net (66.129.241.10) by CO2PR05MB698.namprd05.prod.outlook.com (10.141.229.13) with Microsoft SMTP Server (TLS) id 15.1.409.15; Mon, 22 Feb 2016 22:06:14 +0000 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "John G. Scudder" In-Reply-To: <6928_1455786507_56C58A0B_6928_729_1_53C29892C857584299CBF5D05346208A0F7CE538@OPEXCLILM21.corporate.adroot.infra.ftgroup> Date: Mon, 22 Feb 2016 17:06:06 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <7CAB12D9-9107-45CB-8D05-0F2B930A6B9C@juniper.net> References: <20151006081045.66A82187E04@rfc-editor.org> <008901d169a6$cc3d1da0$4001a8c0@gateway.2wire.net> <6928_1455786507_56C58A0B_6928_729_1_53C29892C857584299CBF5D05346208A0F7CE538@OPEXCLILM21.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.2104) X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: CY1PR1101CA0041.namprd11.prod.outlook.com (25.169.17.51) To CO2PR05MB698.namprd05.prod.outlook.com (10.141.229.13) X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB698; 2:cL2eextnILO/3Ds4AM5CCaTredr43I/Qb4o6OpGvGtzSxYb1j8xfXkMDepQddzqntJ5CWeKtC3KjnFxdvTnMfpB2zXfhKSZiUmHkp/RDjcBvizIT/TPMFlnMlCyhSQfFQFi7C1bxDNiDAzeWxjR5tQ==; 3:vwo87cbxHWUgsRGOTZx4HapHNdntvmIcwt24qoDDhwd7U5t9egCeE2KOcMLXToEg4J5kvbPF+/mTtMgjzzzFFRfvf9PRYmiymuEoEq2DYRWRm5BjM/3VRvxss2L4mMxt; 25:guEIXLDsfYvEOQ37dXe0G+O27AitM5pHOn+lIMBPxHsFAQLzrrswlbpAX+nmctUIxrjPLE0igP7LcAX/2LX1i2ogS7noquAiTTr8v0dPzMOAhxfdjCWD1ok2AWCTl3T44e7FkWxrhELVvDXjFzPXP8nPN31LD9b5RLnLr+EXj5ILMCURZwHL5/fWeLKlVt/hfSzKkvjbsFJnkwstryGOhU65fnvnQ7wftKp4er/uJtqwjG0MLmeAnbVx4H299dNWBak5g6VhzicjpIY8DPoCgSA4jUYwaKQydyHThEf2YBTf1lu3+ifJm+d5SYSWOIWaL1lY9IQibyMArUnPiOcA0AtYPCMy+8XhXUIrhi2OoDQ= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB698; X-MS-Office365-Filtering-Correlation-Id: 50a32181-379f-4e08-08b0-08d33bd461c3 X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB698; 20:az2HBNJBXjCnoKVrtKhiPaCcdZmFnuE5kEtR2xKe22wWI4I1WcAliPoOBpczyMKms0YFqcccOc4o/2oKVPXPoUF3NUKcSv9Ifxi4p94LfDIJQTiUxWmutAS8Pjg5PpqFf8fcEo+DL1knghFN8Piixrmog38MvN7OejlNhLFUoArAdGl6+Qt34QXDiduWKw6J4sSVGSRMl6g/ecHaqKx08XQxFCFfI7CkAm5uo4BqHkUzSDamy7pXHxfdy0kwDK4Uc0459GIRs/9vS2yRH/SLR8DZKKzX5LM8EFds4uDyDTcwRteRb1XzV6l6o6HjrtOBupNkBbuZ71U+28Gf6yiSvJt4UzPoRTn3kStyjxT+8BnPSxgXvsjRYFPHL+wI4AcJxCn47oJ4UQbxTck1Q2eS/8YucS5S5/TMNmjibRBwrRVRqpsQvI65LimrYD+PPxxfMWX855Pq74S9K2prjVgvOFk+21ato3ymKvGajoKlFzoeO3KTYvDmmqPFj9U3Rune; 4:+VxJ57HbBX+AYMmzWqYlytA9TXAwpdYk/aPQBiOAQqkmOEhKp9ZwMyLSdjATndLZzPDpU63ZHbg26MgIBd9mZHztpE/S1QwM0M6nyKT+6oaMUGWq+OkBb7Z7oS/VUbOXvr4+W7+SbO0jS1xl0fn22hNIbZ1nSqeSrWfceZSLTXkzI3Jf/anvWLL7juN9dISi+cJjd8WMB7vLNMC2pWUx22lYVK6hxjmr5A6TFSxqi3CHicPdwJLeCTxGtgnFUrnJSTFmj3zvx+cEh6vrpnxwDl2JKf3TR3iA06/pk0eybTayFugkiqWhhbrjrkxsgSr4C6cM0rimGqwLOYQ4NKVTVhwDQfRBQCJwm5WJH8wAMYduUNNvC7YZ8es7YpR4F8R4 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:CO2PR05MB698; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB698; X-Forefront-PRVS: 0860FE717F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(24454002)(164054003)(377454003)(42186005)(87976001)(53416004)(3846002)(50986999)(76176999)(189998001)(110136002)(5001960100002)(36756003)(93886004)(83716003)(5008740100001)(5004730100002)(2906002)(47776003)(586003)(4326007)(1096002)(66066001)(15975445007)(6116002)(57306001)(82746002)(50466002)(50226001)(92566002)(2351001)(23756003)(86362001)(2950100001)(40100003)(33656002)(122386002)(19580405001)(19580395003)(77096005)(7059030)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB698; H:thuongn-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; CO2PR05MB698; 23:ytcJvb16g/xBXPxbg9+vMV+KJGMvFFE5/ffWF6q4?= =?iso-8859-1?Q?1nBvDixfhO3fiohY8o8m33PzlJsKCilOT2YOOFqS0hA/HzcuqiRF7oiNcq?= =?iso-8859-1?Q?yyyT+sS47gS5XUInfRG05aW9Q0whOjY/Tj2A2CRU7OpKw99jFbxVBYRuxn?= =?iso-8859-1?Q?5UZy5/wrRQyq4Av412/dXLhMxWJDBFJNQ9wdcZ3i8KOUtiEcabxxS5pfGP?= =?iso-8859-1?Q?7Phkph4c6jLr165aA8s54nk0HGZi+BDamBVCMwZhnvPpzI1BllUeG6d/7E?= =?iso-8859-1?Q?5fmMF5sFFlSa5SRjS99I8jN/q3oMaiSC1zkvVJqA8xrAkgLjK9P2b7w5/T?= =?iso-8859-1?Q?rjnYXyHv4HLg5lCsOJ3f0hNyFod9Q6FEoR3PCOMBO39n0QmzOsdk7U95gc?= =?iso-8859-1?Q?vaKsR+vyZqRjtkfboqpkNt5O2WqXwowYQV3P+9G3aI7TtMlPbcg1ukkvdf?= =?iso-8859-1?Q?/aGc81GTfVnheAySNulP4cn3cRsWIi1nqPUz0Nv7qGgUKDJzF1PJzkBMAo?= =?iso-8859-1?Q?X//EgUyAtxsKyC5Hm/rkKxmgj+2wXPJ6s7ZTwiBaVq1ABfl9pLM3iqJa86?= =?iso-8859-1?Q?4mNCRxYtqTg/IWTZ6k87ECvgDket0RMTgzXDwrXq3U2DC5xFVKD7RTz4Za?= =?iso-8859-1?Q?bNIulxFZ+8QZ9h4mg7lK4L/v+Zg68DVQZozx4WbJHYITKXgUyWFyeZBwWK?= =?iso-8859-1?Q?FWFoLT8F8/VE7L5UTK/fEIit/TCQFYWTjKDeS/c2wuZM2v44Akrd61ITbp?= =?iso-8859-1?Q?CbPlCW3dPYWKozJkJWDHbD/ri1eE3wd935PzRYD5vWWz1yCa9BCnrVIHWy?= =?iso-8859-1?Q?7uALh2cyH3yCXSg5Zmm5aCWg8Cio8/tzd7uP4ZZWkxKLzV9FECKaQBDpw3?= =?iso-8859-1?Q?SEszX5RaYEGnmsAfRrKGAm+t/Z/z6171X8wJ1XSejEO8g1/O2d06w28OGY?= =?iso-8859-1?Q?GpDx0raOIQr+jq05pw/w4N5sLnQvE0Whjk6tAU53qFDbJSmRjwcmbWUzKy?= =?iso-8859-1?Q?mtWOytMVr/NYad9pnV2B4IEHTeuYzyIAfP6pE7QWnsuQvWKJvW77BhVSSr?= =?iso-8859-1?Q?IootP9EPeHJ/axuJR8NNsDfTpsq5MxdJXlwAII07hutyZm0lNmw+8lUPFc?= =?iso-8859-1?Q?hVeGy7wqD/vHA+TNoaYFK6zE/Ve5/QKqZc7Lc2Of5tOUL4x7nTNrWJwMEF?= =?iso-8859-1?Q?bY0lIRn2BZr0UsbEEtjZ9m0KdM/esnf8pF2gdExfC3BRNGoynXyKw=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB698; 5:yJfy4+t8FA1tqM95fZIgC6YossSUWXcLDNtICEVzHd2Mn6OxzA7EA0pxlGZNxepMgxAIBrM+7QhCecy6vggbdVwMZ7JrtryxKv2BqzpITCL/vI19PJoS4s4ywQ+1kT0A+vUsNO+VtTJhAuN5rG0aIg==; 24:QA+lOoinnT3D42bumOZV976r09+izqro05Q/+3lnV4qwlVuafIjdcTOzM0P81dSkiP32Q/cA85qc6nR0turLgg8M2IpK4oztUm9u448zyW0= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2016 22:06:14.0211 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB698 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (4493) 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, 22 Feb 2016 22:06:41 -0000 On Feb 18, 2016, at 4:08 AM, bruno.decraene@orange.com wrote: >=20 > I don't think you can call "implementation error" a behavior which is = specified in the RFC: > "If no appropriate Error Subcode is defined, then a zero (Unspecific) = value is used for the Error Subcode field." > https://tools.ietf.org/html/rfc4271#section-4.5 >=20 > This sentence is generic and applies to all error codes. I find this argument compelling. IMpersonalO the erratum should be accepted and the registry updated as = others have suggested. N.b. I also prefer "Unspecified" to "Unspecific" = in the registry. Thanks, --John= From nobody Mon Feb 22 16:02:03 2016 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 C265A1A8A4E for ; Mon, 22 Feb 2016 16:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, 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 DA4Vs8bSzz8K for ; Mon, 22 Feb 2016 16:01:56 -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 6C6241A8A17 for ; Mon, 22 Feb 2016 16:01:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJA00811; Tue, 23 Feb 2016 00:01:52 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 23 Feb 2016 00:01:50 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Mon, 22 Feb 2016 16:01:40 -0800 From: Linda Dunbar To: Wesley Eddy , Justin Dailey , "idr@ietf.org" Thread-Topic: more suggestions to draft-eddy-idr-flowspec-exp-00 Thread-Index: AdFkdIg/gEit8njdRkCD1YGUWCwNWgJfob2AAAwp+uA= Date: Tue, 23 Feb 2016 00:01:39 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657DEE702@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657DEA4A3@dfweml701-chm> <56CB701F.5010500@mti-systems.com> In-Reply-To: <56CB701F.5010500@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.236] Content-Type: multipart/mixed; boundary="_004_4A95BA014132FF49AE685FAB4B9F17F657DEE702dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.56CBA171.0054, ss=1, re=0.000, recu=0.000, reip=0.000, vtr=str, vl=0, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: db441dc6e90e8e1c20798c3612791fce Archived-At: Subject: [Idr] more suggestions to draft-eddy-idr-flowspec-exp-00 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, 23 Feb 2016 00:02:02 -0000 --_004_4A95BA014132FF49AE685FAB4B9F17F657DEE702dfweml701chm_ Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657DEE702dfweml701chm_" --_000_4A95BA014132FF49AE685FAB4B9F17F657DEE702dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Wes, Thank you very much for the reply. Since my writing to you a week ago, I'v= e done some study of other IDR FlowSpec related drafts (there are many of t= hem). I think it is worthwhile to look at all flow Spec approach holistically lik= e https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/ First of all, I believe that Flow Spec is very useful for influencing rout= es (as described by the Section 3 of https://datatracker.ietf.org/doc/draft= -li-idr-flowspec-rpd/ ). It is great to see many extensions to make IDR Flo= wSpec more comprehensive. However, Flow Spec is far from enough for mitigating today's sophisticated= DDoS attacks. As in Amazon's AWS service where attackers are from leased v= irtual machines, more and more DDoS attacks do originate from legitimate so= urces (i.e. the approach described by RFC5635 has more chance of dropping l= egitimate traffic than the DDoS attack packets) . Therefore, IMHO, the "Introduction section" of your draft shouldn't focus = on what Flow Spec is missing when used for Anti-DDoS, because there are a = lot more missing. The "extension" you described is not enough in mitigating= the modern DDoS attacks. There is a working Group DOTS whose purpose is fo= r DDoS mitigation. Instead the "Introduction" should describe the general structure of IDR Flo= wSpec, to make RFC5575 more complete in influencing routes. For example, I think the following items should be described for Flow Specs= : - Flow Specs consists of two major components: Matching criteria and= Actions. The Matching criteria are carried by NRLI, the Actions are carrie= d by BGP extended Community. - For Actions: there are two major categories (Separating Control Pla= ne policy from the data plane policy ) o Data Plane action: The Actions for local node, i.e. ACL actions to= routers, such as Rate Limiting, forwarding, egress, tunnel, etc o Control Plane action: The Actions for how the routes is propagated = to peers and its priority (or the precedence) if conflicting with other rou= tes. - Your draft is to describe the extension of Matching Criteria & Acti= ons for Packet Rate action, the Tunnel Description, Flow Spec identifier, e= tc. Attached is my suggested wording for the introduction of your draft. Best regards, Linda Dunbar From: Wesley Eddy [mailto:wes@mti-systems.com] Sent: Monday, February 22, 2016 2:31 PM To: Linda Dunbar; Justin Dailey; idr@ietf.org Subject: Re: questions to draft-eddy-idr-flowspec-exp-00 Hi Linda, thanks for the feedback, here are some answers inline: On 2/10/2016 9:33 PM, Linda Dunbar wrote: Wes, et al, I have some questions to your draft-eddy-idr-flowspec-exp-00: 2.1. Packet Rate Action: Is the "packet rate" described here intended for "matching condition"= ? (same way as the matching types proposed by RFC5575? No, it is intended as an action applied to traffic matching the filter. In= flowspec/5575, the community attributes are used to indicate the action, w= hereas the NLRI indicates the matching criteria. 2.2. Tunnel Description: - To match a flow with specific outer tunnel and inner TCP or UDP, "= logical operators (AND, OR, NOR)" should be enough. Why need to specificall= y state "tunnel"? - The "Offset-Value-Mask" matching is not intended to be propagated t= o other peers , is it? Yes, if not propagated to other peers, it wouldn't be useful to include in = BGP :) - Page 7 last sentence: what does "A" mean in "to address A within a = GRE flow to address Pout ..."? That was just intended as a variable "A". It could have been any other sym= bol. 3. Other discussion: You stated that RFC5575 can be translated easily to ACL. The Matching= & Action can. But ACL is local to the node, which are not propagated to pe= ers as specified by RFC5575. Agreed. For the Anti-DDoS use case, Controller may only wants to impose the A= CL for a specific node, instead of sending a big wave to all the ASs. Othe= r ASs may have its own Anti-DDoC controller temporarily steering some suspi= cious traffic to its own security scrubbing center. Propagating Anti-DDoS s= teering policies to other ASs can make the large network oscillate violentl= y (& unnecessarily) . The logic for controlling distribution of updates is a separate problem, an= d actually more difficult than just defining a wire format. You are defini= tely correct that this logic and the configuration settings in practice are= very important to successfully deploying something like this. That logic = doesn't really need to be standardized IMO, though, since it can be differe= nt in various ASes or products, as long as they can communicate over the wi= re. To contain the unnecessary complexity, there should be two types of F= low Spec control: - Distributed, i.e. flowSpec coming from (or propagated to) peers. - Centralized, i.e. "Flow Specs" coming from its designated "controll= er". Under the "Centralized" mode, there should be a mode that doesn't pro= pagate received route policies to peers (i.e. localized policy). Under thi= s "Centralized & no propagating" mode, a lot of tricky issues (like securit= y) goes away. That would be one possible implementation approach, IMO, though there may b= e others, for instance with subsets of rules to redistribute indicated in p= olicies on a neighbor-by-neighbor basis. --_000_4A95BA014132FF49AE685FAB4B9F17F657DEE702dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Wes,
 
Thank you very much for the reply. Since my w= riting to you a week ago, I’ve done some study of other IDR FlowSpec = related drafts (there are many of them).
 
I think it is worthwhile to look at all flow S= pec approach holistically like https://datatracker.ietf.org/doc/draft-har= es-idr-flowspec-combo/
 
First of all, I believe that Flow Spec is ver= y useful for influencing routes (as described by the Section 3 of https://da= tatracker.ietf.org/doc/draft-li-idr-flowspec-rpd/ ). It is great to see many extensions to make IDR FlowSpec more comprehensi= ve.
 
However, Flow Spec is far from enough for mit= igating today’s sophisticated DDoS attacks. As in Amazon’s AWS = service where attackers are from leased virtual machines, more and more DDo= S attacks do originate from legitimate sources (i.e. the approach described by RFC5635 has more chance of dropping legitim= ate traffic than the DDoS attack packets) .
 
Therefore, IMHO, the “Introduction secti= on” of your draft shouldn’t focus on what Flow Spec is missin= g when used for Anti-DDoS, because there are a lot more missing. The “= ;extension” you described is not enough in mitigating the modern DDoS attacks. There is a working Group DOTS whose purpose is for DDo= S mitigation.
 
 
Instead the “Introduction” should = describe the general structure of IDR FlowSpec, to make RFC5575 more comple= te in influencing routes.
 
For example, I think the following items shoul= d be described for Flow Specs:
 
  • Flow Specs consists of two major components: Matching criteria and Act= ions. The Matching criteria are carried by NRLI, the Actions are carried by= BGP extended Community.
  • For Actions: there are two major categories (Separating Control Plan= e policy from the data plane policy )
    •
  • Data Plane action: The Actions for local node, i.e. ACL actions to rou= ters, such as Rate Limiting, forwarding, egress, tunnel, etc
  • Contr= ol Plane action: The Actions for how the routes is propagated to peers and = its priority (or the precedence) if conflicting with other routes.
 
  • Your draft is to describe the extension of Matching Criteria & Acti= ons for Packet Rate action, the Tunnel Description, Flow Spec identifier, e= tc. 
 
Attached is my suggested wording for the intro= duction of your draft.
 
Best regards, Linda Dunbar
 
 
Fr= om: Wesley Eddy [mailto:wes@mti-= systems.com]
Sent: Monday, February 22, 2016 2:31 PM
To: Linda Dunbar; Justin Dailey; idr@ietf.org
Subject: Re: questions to draft-eddy-idr-flowspec-exp-00
 
Hi Linda, thanks for the feedback, here are some= answers inline:

On 2/10/2016 9:33 PM, Linda Dunbar wrote:
Wes, et al,
 
I have some questions to your draft-eddy-idr-flowspec-exp-00:
 
2.1. Packet Rate Action:
 
Is the “packet rate” describe= d here intended for “matching condition”? (same way as the matc= hing types proposed by RFC5575?


No, it is intended as an a= ction applied to traffic matching the filter.  In flowspec/5575, the c= ommunity attributes are used to indicate the action, whereas the NLRI indic= ates the matching criteria.


 
2.2. Tunnel Description:
-  To match a flow with specific out= er tunnel and inner TCP or UDP, “logical operators (AND, OR, NOR)R= 21; should be enough. Why need to specifically state “tunnel”? =
 
  • The &= #8220;Offset-Value-Mask” matching is not intended to be= propagated to other peers , is it?

Yes, if not propagated to = other peers, it wouldn't be useful to include in BGP :)

  • Page 7 last sentence: what does “A” mean in “to addre= ss A within a GRE flow to address Pout …”?
 

That was just intended as = a variable "A".  It could have been any other symbol.


 
3. Other discussion:
 
You stated that RFC5575 can be translated= easily to ACL. The Matching & Action can. But ACL is local to the node= , which are not propagated to peers as specified by RFC5575.

Agreed.


 
For the Anti-DDoS use case, Controller ma= y only wants to impose the ACL for a specific node, instead of sending a bi= g wave to all the ASs.  Other ASs may have its own Anti-DDoC controlle= r temporarily steering some suspicious traffic to its own security scrubbing center. Propagating Anti-DDoS steerin= g policies to other ASs can make the large network oscillate violently (&am= p; unnecessarily) .

The logic for controlling = distribution of updates is a separate problem, and actually more difficult = than just defining a wire format.  You are definitely correct that thi= s logic and the configuration settings in practice are very important to successfully deploying something like this.&= nbsp; That logic doesn't really need to be standardized IMO, though, since = it can be different in various ASes or products, as long as they can commun= icate over the wire.


To contain the unnecessary complexity, th= ere should be two types of Flow Spec control:
  • Distributed, i.e. flowSpec coming from (or propagated to) peers.
    • <= li>Centralized, i.e. “Flow Specs” coming from its designated &#= 8220;controller”.
 
Under the “Centralized” mode,= there should be a mode that doesn’t propagate received route policie= s to peers (i.e. localized policy).  Under this “Centralized &am= p; no propagating” mode, a lot of tricky issues (like security) goes away.
 

That would be one possible= implementation approach, IMO, though there may be others, for instance wit= h subsets of rules to redistribute indicated in policies on a neighbor-by-n= eighbor basis.
 
 --_000_4A95BA014132FF49AE685FAB4B9F17F657DEE702dfweml701chm_-- --_004_4A95BA014132FF49AE685FAB4B9F17F657DEE702dfweml701chm_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="Suggested Text for the Introduction section of draft-eddy-idr-flowspec-exp.docx" Content-Description: Suggested Text for the Introduction section of draft-eddy-idr-flowspec-exp.docx Content-Disposition: attachment; filename="Suggested Text for the Introduction section of draft-eddy-idr-flowspec-exp.docx"; size=16813; creation-date="Mon, 22 Feb 2016 23:54:41 GMT"; modification-date="Mon, 22 Feb 2016 23:54:50 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDJMTxZgAEAACIGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 VMtOwzAQvCPxD5GvKHHLASHUtAceR6hE+QDX3rQR8UNep4+/Z5OUCEGbAmkvkZz1zszO7no02egi WoHH3JqUDZMBi8BIq3KzSNnb7Cm+ZREGYZQorIGUbQHZZHx5MZptHWBE2QZTtgzB3XGOcglaYGId GIpk1msR6OgX3An5LhbArweDGy6tCWBCHCoMNh49QCbKIkSPG/rdKPFQIIvum4sVV8qEc0UuRSCl fGXUN5Z4x5BQZn0Hl7nDK5LB+F6GKnKYYJf3Qtb4XEE0FT48C00y+Np6xZWVpaYakm6YPTptluUS 2vwKzXkrAZE810XSRrTIzaf+gzpMqefgKfP0QlrooyIwbAvA0ytocLvoyayptw45DUdvfqjGT4GK qR8OfMihnZ+D/iOEQO6fo/gd8q/KlyUGq3s70MD8pf5AGw+8/g5709cwXfXWq5fRozAT8wJ68/3Y vRb6qIg1zF/P1vov4F1C2uGX1v/DjM8Hs8re03Jev/DjDwAAAP//AwBQSwMEFAAGAAgAAAAhAJlV fgUEAQAA4QIAAAsACAJfcmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACsks9Kw0AQxu+C77DMvZm0iog06UWE3kTi Awy70ySY/cPuVNu3dy2IBmrSg8ed+eab33zsenOwg3rnmHrvKlgWJSh22pvetRW8Nk+Le1BJyBka vOMKjpxgU19frV94IMlDqetDUtnFpQo6kfCAmHTHllLhA7vc2floSfIzthhIv1HLuCrLO4y/PaAe eaqtqSBuzQ2o5hjy5nlvv9v1mh+93lt2cmYF8kHYGTaLEDNblD5foxqKLUsFxuvnXE5IIRQZG/A8 0epyor+vRctChoRQ+8jTPF+KKaDl5UDzEY0VP+l8+GgwR3TKdorm9j9p9D6JtzPxnDTfSDj6mPUn AAAA//8DAFBLAwQUAAYACAAAACEAs76LHQkBAAC2AwAAHAAIAXdvcmQvX3JlbHMvZG9jdW1lbnQu eG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACsk89KxDAQxu+C7xDm btOuuohsuhcR9qr1AdJ2+gebpCSzat/eobDbLi710ktgvpDv+80w2e1/TCe+0IfWWQVJFINAW7iy tbWCj+z17glEIG1L3TmLCgYMsE9vb3Zv2GniR6Fp+yDYxQYFDVH/LGUoGjQ6RK5HyzeV80YTl76W vS4+dY1yE8db6ecekF54ikOpwB/KexDZ0HPy/96uqtoCX1xxNGjpSoQMSMSdBfbUvkZScFIi5gR5 HWGzKgINHc9wAhjrpfhkzXh7NDl6nsFEcJaWILZrQhCvB04AYynHM1lieFyToXKWMp13M46ztATx sCbEN+bvf1ZyJp5A5MVvS38BAAD//wMAUEsDBBQABgAIAAAAIQC+EIbd2QgAAAg1AAARAAAAd29y ZC9kb2N1bWVudC54bWzsWt9v2zYQfh+w/4HwUws4dtou6WA0Ltr82AJkQ5BmT8MeaIm22VKkQFJW nL9+31GSYylO4ai2m3TLQ5xI5PF49913x6Pfvb9JFJsJ66TRR51Xvf0OEzoysdSTo85f12d7v3aY 81zHXBktjjpz4Trvhz//9C4fxCbKEqE9gwjtBjO8nXqfDvp9F01Fwl3PpELj5djYhHv8ayf9hNsv WboXmSTlXo6kkn7ef72/f9gpxZijTmb1oBSxl8jIGmfGnqYMzHgsI1F+VDPsOusWM09KlcOKfSsU dDDaTWXqKmlJW2nY4rQSMvvaJmaJqsbl6TqrxZbn8EeiCrVzY+PUmkg4h6cnxcuFxFf7X1u7NCCJ WMxYR4X6mpUmCZd6IYbQ0fD/wnk9OK9frN0nUXcbgS2GwNLIxHP6TFk+ABbjq6POPn7enpycdqpH J2LMM+WX3vTvTTk8O3h1CiyVUi6BDWCr/nBJTv3N5dLgIPnSho9Pfq4ERM64OupcSOcvueUTy9Np J2igs6QYKdVMVeP2F+/O4+rZa3rWzweLCbaY524XI34pprnbY1d/hmlhND7TYpbFgGCr2i5J4xZi 84EfnmtvTZxFFBOkpg/Kwga05k5MLTXZSokxvPzmsDRhi91s0UjXU8HOlMnZp1REEnQUKIS9qBkM 9rLGjE8t+cjPU4SGS4VSnzy3vvDwxr03hlJYJFpLkVMdb0mNl+zvq7Pjg4O3B/8wceOFpszCvGEf f7tkPJtQxnANHUOYtXAzbEtZY+BSHsHEqRVO2JnoDFlzgU2HigcKpC4SG+0vMnom5iJmfmpNNpmG 3WLTI+G9sGzMI8p03AuWGCswPEmVuGHecspozMmJ5j6D/hDANfucOY+/RHMb7YP7+9hp9aqxcF5i v2Q4VBYsNchkIzVnzmQ2EozHMSzhCmN4dnX98fd7Dt20JQJoD98AtE2bbxg6q02SeeDjVrjeveXb b3R4veWtDHcA0JJLmmZ5NvTa3n2rgdI0xMbTSCIiMJB0CUO9hnMB44jPXNhxplgiuHZ4XvCVQvXJ Mo1olpaYr+CyJuaenQGWuDhLnbeCJ12WTwVoG4yM37KwCXFWOL4QZXuGFPRFeMci0Pfo2RP3MNm2 HykNCiAM1eZMgPvHUiFTirjBgOuUno8t6LdQZW4a5VRl/sF9NKUYoxz5IVTljlGFh6oT8TaaEx5Z RZAc9sQ5HklUJlJxSyXXh+OLLhtloZSYMxrhlJxMPcwdS4puOr2PrUloJOqZAskLic7hfA+wK8Wo uAxrk1haFlUOFTYkE1yc8glqG3CAYakAaZQBw6mcQdhYHkvK9lyFhUoR2sTI9RCgDcLnvpAWSKid hKrE/QTgUalS0689ZoaLAwh6MxYHtsyKQS1gn0nYbNguq1PmwlggZzR7cH4POcznhiX8s7GhGkdz C+eSAbuLushKIFzy5fBrAcnHoi/dWLfh8El3G1b7qsZ7dx4ASUTc2pL2/ry6OO8Gtzwa87UArND3 w7joGxhl22eF1e5GcqgSGyWCJR9TtyC0D2KklWOTJJlGp7hF/G3E41uoGCrw1fT7BgeeGVuLBnQB 20tb7S1K5s01NryNBxYuQTIgDYATwkpTkfabHSboKkv0Y5oid7M3NBDFxIDbkH1qGqyTw2voqfT9 fnx28KRTzpCyS8U36N0xZSKUpFSHdpnsiR4L5SkvS22UqUWVi3LWZdGUoZy9ohbeBSpsNLAmXQYh Obd0WdZlYkJNqy7zmdZC4X/fbMVuPCB7jHa0pO/dhhaFNXYxWlmjN7gUfFHhpwaq9nH1QCw/GuP/ wzlcPL0OV0MghbJR/kDru4nxKQ5uYM0Cyo6aFyuOWj9EMbVh8mkPfOKZGsp3Fluplcgkfs5egN3I 67gSiUSMG33xsqlR+/09ENjoC9KSoVVAl2PNBXdDL3JMp7yxkmBx9E5y6afMQC9bRkCD9naWZJ9+ CbnarefUFQJrVN/2QGsnpJOZpO4Nw1X2CLaF72UCYpmJcL9XdYnEDU7b5IYGFjDyP3k7utrE6KtX PffQSk442qHGUX+tNCrdkaEHH2g6XBUhxNGukxpj9mJD38MA6pXiI2OLezWkfZelqbGeGb0X4+s4 aCKGcgaiEBzoAJZ9e/QRI2E9ieBpilfFd2J6NZetEyaPzdNbiIj2nAbOlveupXfDWDEuTnwzQjZe K+YSbdyaT3eVlQA0dHJQhFJ2uPtKQFOX9r6rRdW/AAAA///sV19v2jAQ/ypWnlppWlNGYapKpIk/ U6V2imBfwDiXxJpjW/YFSj/9bIcwGLzQQvfAHhLZ57PPd7773Z0BC2YBUYKKPNws7zHxf5M8uB9x n+XZNDWDKI57k7vbcS8KK2lgsK+OY0HFIOp0oxu/YF+HdpfmD2u4kbxU4t5qymAQ6Y3cZ4qs5LIg Q8MRDKd713i7xOTqx/Tp8ZpQmREs4Z/oR74x5EraE6p12JBX8IIgM8gIU1VVS46r6z2hH/KkuTK7 gp0TaP+KuhW/5U8taQQ5rQXur6RbpHBI4056hisBrbM9cYspNbQwVJeNL8q6aji5WIiWL96sPWYt re9p7oqbDWuHPca9vYaNtI+JmpSyX4BkShEIDQ726b/JzwtUDkDIz1pKEGQElhmufVxfsNm1USof G+/wuNIO1K0GIWZIDTZR1mSRJiyOCSafhSZCLc+M18lMA/tLxmGdxjJba+R0PX9KJDwDiTznYC7Y vd7jPUOz0qhCMuCMjGVJJYPKGXXnuS8qLb29ijpcbvgAdUAooKAeBy83+xyGjBPCoIPVY2Hq1I9N JgDZ3NUcn49/553uocXPk1d776jZWhiwwDDdlG9bVWd76UOazNwmzxrH/dFoHLojXcx8Y7QcRLed TjeO3Lh047uvbhy6JF0805A1lXb0bsNieFG6k9rpXCGq6s9cQL61WgLNwHVl/U44PlfKtU6baVFj mK7FMSV8U7buvPyWcItMse+G+ypYcAkpd23YIPrSC6vOJI01QmE8V9kqDNyW2qNo8hsAAP//AwBQ SwMEFAAGAAgAAAAhAJa1reKWBgAAUBsAABUAAAB3b3JkL3RoZW1lL3RoZW1lMS54bWzsWU9v2zYU vw/YdyB0b2MndhoHdYrYsZstTRvEboceaYmW2FCiQNJJfRva44ABw7phhxXYbYdhW4EW2KX7NNk6 bB3Qr7BHUpLFWF6SNtiKrT4kEvnj+/8eH6mr1+7HDB0SISlP2l79cs1DJPF5QJOw7d0e9i+teUgq nASY8YS0vSmR3rWN99+7itdVRGKCYH0i13Hbi5RK15eWpA/DWF7mKUlgbsxFjBW8inApEPgI6MZs ablWW12KMU08lOAYyN4aj6lP0FCT9DZy4j0Gr4mSesBnYqBJE2eFwQYHdY2QU9llAh1i1vaAT8CP huS+8hDDUsFE26uZn7e0cXUJr2eLmFqwtrSub37ZumxBcLBseIpwVDCt9xutK1sFfQNgah7X6/W6 vXpBzwCw74OmVpYyzUZ/rd7JaZZA9nGedrfWrDVcfIn+ypzMrU6n02xlsliiBmQfG3P4tdpqY3PZ wRuQxTfn8I3OZre76uANyOJX5/D9K63Vhos3oIjR5GAOrR3a72fUC8iYs+1K+BrA12oZfIaCaCii S7MY80QtirUY3+OiDwANZFjRBKlpSsbYhyju4ngkKNYM8DrBpRk75Mu5Ic0LSV/QVLW9D1MMGTGj 9+r596+eP0XHD54dP/jp+OHD4wc/WkLOqm2chOVVL7/97M/HH6M/nn7z8tEX1XhZxv/6wye//Px5 NRDSZybOiy+f/PbsyYuvPv39u0cV8E2BR2X4kMZEopvkCO3zGBQzVnElJyNxvhXDCNPyis0klDjB mksF/Z6KHPTNKWaZdxw5OsS14B0B5aMKeH1yzxF4EImJohWcd6LYAe5yzjpcVFphR/MqmXk4ScJq 5mJSxu1jfFjFu4sTx7+9SQp1Mw9LR/FuRBwx9xhOFA5JQhTSc/yAkArt7lLq2HWX+oJLPlboLkUd TCtNMqQjJ5pmi7ZpDH6ZVukM/nZss3sHdTir0nqLHLpIyArMKoQfEuaY8TqeKBxXkRzimJUNfgOr qErIwVT4ZVxPKvB0SBhHvYBIWbXmlgB9S07fwVCxKt2+y6axixSKHlTRvIE5LyO3+EE3wnFahR3Q JCpjP5AHEKIY7XFVBd/lbobod/ADTha6+w4ljrtPrwa3aeiINAsQPTMR2pdQqp0KHNPk78oxo1CP bQxcXDmGAvji68cVkfW2FuJN2JOqMmH7RPldhDtZdLtcBPTtr7lbeJLsEQjz+Y3nXcl9V3K9/3zJ XZTPZy20s9oKZVf3DbYpNi1yvLBDHlPGBmrKyA1pmmQJ+0TQh0G9zpwOSXFiSiN4zOq6gwsFNmuQ 4OojqqJBhFNosOueJhLKjHQoUcolHOzMcCVtjYcmXdljYVMfGGw9kFjt8sAOr+jh/FxQkDG7TWgO nzmjFU3grMxWrmREQe3XYVbXQp2ZW92IZkqdw61QGXw4rxoMFtaEBgRB2wJWXoXzuWYNBxPMSKDt bvfe3C3GCxfpIhnhgGQ+0nrP+6hunJTHirkJgNip8JE+5J1itRK3lib7BtzO4qQyu8YCdrn33sRL eQTPvKTz9kQ6sqScnCxBR22v1VxuesjHadsbw5kWHuMUvC51z4dZCBdDvhI27E9NZpPlM2+2csXc JKjDNYW1+5zCTh1IhVRbWEY2NMxUFgIs0Zys/MtNMOtFKWAj/TWkWFmDYPjXpAA7uq4l4zHxVdnZ pRFtO/ualVI+UUQMouAIjdhE7GNwvw5V0CegEq4mTEXQL3CPpq1tptzinCVd+fbK4Ow4ZmmEs3Kr UzTPZAs3eVzIYN5K4oFulbIb5c6vikn5C1KlHMb/M1X0fgI3BSuB9oAP17gCI52vbY8LFXGoQmlE /b6AxsHUDogWuIuFaQgquEw2/wU51P9tzlkaJq3hwKf2aYgEhf1IRYKQPShLJvpOIVbP9i5LkmWE TESVxJWpFXtEDgkb6hq4qvd2D0UQ6qaaZGXA4E7Gn/ueZdAo1E1OOd+cGlLsvTYH/unOxyYzKOXW YdPQ5PYvRKzYVe16szzfe8uK6IlZm9XIswKYlbaCVpb2rynCObdaW7HmNF5u5sKBF+c1hsGiIUrh vgfpP7D/UeEz+2VCb6hDvg+1FcGHBk0Mwgai+pJtPJAukHZwBI2THbTBpElZ02atk7ZavllfcKdb 8D1hbC3ZWfx9TmMXzZnLzsnFizR2ZmHH1nZsoanBsydTFIbG+UHGOMZ80ip/deKje+DoLbjfnzAl TTDBNyWBofUcmDyA5LcczdKNvwAAAP//AwBQSwMEFAAGAAgAAAAhAFf6CkEZCgAAZikAABEAAAB3 b3JkL3NldHRpbmdzLnhtbJxaWW8byRF+D5D/IPA5svo+iJUXfeaAvQmi3R8wIkcSYQ6HmBlZ9v76 1JDiyk6+WSzyJKprurrurqquH3780u2vPrfDuOsPtyv+jq2u2sOm3+4Oj7erX36u1251NU7NYdvs +0N7u/rajqsf3//5Tz+8rMd2muiz8YpQHMZ1f7t6Hg7rcfPUds143e02Qz/2D9P1pu/W/cPDbtO+ /lm97hhuV0/TdFzf3Lxuetcf2wNhe+iHrpnGd/3weHPemfvNc9cephvBmLkZ2n0zEcHj0+44XrB1 /y82OurpguTz7zHxudtfvnvh7Pe+fGX3pR+2v+34I+TNG45Dv2nHkSTb7c/sds3ucEEz7v8InrM8 P+zuh2b4+g2S96S2X/u+u3pZH9thQwK9XVm2upnX6dz+4W5qppag47Hd7082sNm3DZ3+sn4cmq5r SGfnldOebfvQPO+nn5v7u6k/0kefG6LPileUm6dmaDZTO9wdmw1hS/1hGvr95btt/1M/pb47DsTv mQiylWMzzeQ8j20tH5qv/fNER928rN9AZKzbcf5m/vHvvp8uCBnL3nBrz7hm6BuEMZ59xRCTo8YQ m3OBEK7Nwh4hQ41wj9beSwgxTEmFIULUACFWVIX3WOOzwHtM9BjilRf4HG+F5BBb4s5BCjhjtUC5 cSai8AgbF1YkByGSpZQxRFgPNcel1gFToGxU0EK4Ft5h2rSpGtoOt9J5vMdavUC1tSFifhzP2Ha4 E1pDq+KeBZGgdLz01mCI5hXqlHubNbQDHmTimIJg1MXjv/c5Hqz3eE9k2mD9RF4itqqoi8dUF+MC tAPBtS5QBkLYEKDmhNTJQi8RisUCNScUNwzSJjQTCZ+jOcPRRRhWBZSOMNJinxPGmgyji7CSa+hZ wmomMafWxIQhjjMLLUQ4aQLUtnCqZOhzwhmnMNXOJBwTBUWqBL1ReJmwXQtvKPIgXxCBc/V6X31v vSJyl7G2o8jYRkWUNmB7i8YwTEHSRmMLyTxWzGlWoWAtVCsZ5EcynbEvkH2QdyPpSMq39BJECygd KXlNkDYpRXFQBlIqyaEdSGk0tkSpRC6YU8OyEZAfI5TBtDm6MKAWpNNFLUAsT1g6zgYHLV56oQXm NFCKAm1HBkYKgvwErj3eE23BWYDMnK5niC1ThsIXIEXCGCKLsQliU1xyfNcTJGLaKIwWBjWnhEg4 31FCGw5vDCVZqAsQniPkVEmbNObHcoftQFkpceRTVkmcBSgnRYa+rTxL2K5V0MVifqJwC/xETbEC 6VQlyQ20XpV5clgGmRcJPVgVYTi0RIIkhjktisiGtFVNSR+C0I1FSdICJOPYqwWvGUYKLZSMS5DI odxoT5IYIkXKUD9ayhghp1oagf1HKwrYMO5oLUSG1qu1ppIFSsfMCQ+G6KQX9uiCsw1tdagaYrOU h2BOnYkc7/Ey4Cimg6UEAZ4T5ULs1VGbBU6ryjgXM4w5XOVQWhfwXWKYjDinoHKOYT81guI/5Icu poC9xEjBJbR4I43DOTll5DEKJDejrMOZt9HSMRjjjaHaGdqbMdrimGjoaqwYm+MeR2VStWPQQoyz usIb0HhFZENOqZLgMIYYytJwnmgoUkUY+UyimIjPycrgutFkZT3Wdp69G1KdyeKgN5qqKvYSqk45 zuwso/wN2o7lZDuQH0uVOI4hBJEKY9OWBIT4sXQ34+gyF8gaU0AdDFwHk+1SqwSek4XgUHOWMhQD JWor0wLzQ7LGea/jJDmoOSeocoQ+56T1BUrHUUUpIT9UFmXsP06zBS9xmiQKs06nLeUbSG7OUNyB t4zziopKuCewkqDmXBAWV1MuyOrg/eMovkbopy4ZjvsHBKHaCNKWFVuAFMk41LarSkfMaVXBwT2e UTxYgBjpoKw9Mxn33zyzOcBo6Tmnwhpx6qkHiTMuL4xPUDpe2BQNxCZ5xHejl8LgeECQimOip/4b vn88+YLCFFDqXbHcKIIsSEczbrHcKOnDmarXylRob15bhjtm3tEeaCHU0nUL2LyRGZ8TRA7Qf3yQ zMLo4qPSCnMaTVmwxCQsriSoQRwr9HpPXpKwfooKOEcKjCWcXwdmBb5/wtzYhlE5KGqMQQqCobRq ASKp0YbsOhiZcGcuGB0Y9KzgNLXZIDanvYKRPHhVcFcqeCocoTeGoDy+s0KgZnSFFETKIDFtUZHy 8B6dcT8x0H2xoLlCMR7rp3CNLSQULRi0+FBsxLVmqNJqqNO5RYwz4kiu7aAMoiTnhn5KTX+JZR21 4riDToVExfd2NEriblE0cw2GtEANwIwjRbQyKCi36Mi1oE6jUxH3IGPgCXdoqSQIuEccqUuAq4KY lFuQdRECdzRjnfutUAbU18YdzVhVwpVEYlRtQgtJfH6VQOckLrKAWkjUlcJ5b5IsYw9OSooAvZEg BeeWSfOFeJ0MNQAxP8bUhXOonMLZYLL0igCjC0Goswyl41goeI/XAb+bpSgF7r9RQkE3AzwnyYqr tpSoaYglmnmNGEJvcEmhc7LQRcConKVi+CUyz31lvEfZgqVDRRs9WEAKKPN2GJuR1UIbzZaCFdRC dtQMwBAvTcEUeGJnAbL0Jp49VQVQ1pSeUJsLchqo4oe+nYOlzhjck5jCL56ZRIqjMkGMhOcUen/C r0lFsIw7TBSqOK5yChUsOOOi5qTEN20xrASBOC2Wc9w9pkbaQrZeAo+4X1UoC8DZRkk2eng7l7yU J9ITHPfQT0uRFWuhMur9QC1UoTJ+x6ALXWJ+qqZKHNpoNYopKNFKMRH7D5UepCGkheoEw91JgjiD 9wQm8At7DfQiAL2kJkb4IAWJJQXz+Ep9ioU9mbJBjI06+Az2NmrW5EGQgmy8wVQXqbH1UrCO4eTB NG8zP4bSlE23nuej/jVcflWa4bnqzoM+qenuh11z9XGeoKIpnW59P3yKu8MFft/SJFf7LeTu+f4C vL4+A8au2e8rzQldADQ8dYZsd+Mxtw8nxPuPzfD4hvlkkt16gKs0lfSP37DNQ07t8Nehfz6esb4M zfHvhy0tXw7k6hzQuvXuMH3YdZf18fn+7rLrQINU34CeD9t/fh5mhDdvAnpZTzT71s4S+tAcHi+z R+3h+pe7eYKqbcYpjLvmdvXr03X6ad5NY0374W4emWs/NscjzUjRd/eP/Ha13z0+TXzeNtF/22b4 dPrn/lG8wsQJRv/NsNM/zWZmlr5+/TF/cP5JX73+eFuTlzX5tqYua+ptTV/W9NuauayZee3pKw2T 0bTYJxpNu/yc1x/6/b5/abd/uyzerv5n6SyE8ak5tqTqeZiMbK5fnxZep8vGq8/r9gtNqrXb3UTT iMfdtmu+3K4EO1d8r1/vT7Ni3307Y5o/Pn63erVtJtLB6ba++W7zac7sv2h5WW/bzY5s9O5rd/82 u/buTPh+N0537ZHG3KZ+IJZP829/OdnF24Dk+/8AAAD//wMAUEsDBBQABgAIAAAAIQA76DjIOgEA AKUCAAAUAAAAd29yZC93ZWJTZXR0aW5ncy54bWyUUstOwzAQvCPxD5Hv1CGIAlGTSlXVEycoH+Da m8aS7bVsN6H9erYJj/I40JPXO7Pr2R3P5q/WZB2EqNFV7HqSswycRKXdtmIv69XVPctiEk4Jgw4q tofI5vXlxawve9g8Q0rEjBl1cbEMFWtT8iXnUbZgRZygB0dYg8GKRNew5dg0WsIS5c6CS7zI8ykP YEQiBbHVPrL3bv1/uvUYlA8oIUYSYs3YzwrtWE0ale7i+5n1pVY04vRhWhS3xc3dQNig2i91R2An DKGMH+lWhEdo0kc2/8w+6W37R3qN/jd3gSmh/ZEnQQsVjm+krxpHq2VEjIeKkQEUeCFp2UMs0SAt VuwSjjLMibLzKjffFJ1XG04nP6eUDy4MQ49hPRvPwRj0SVt9gBWGRcA+QiADCD/5XPUbAAAA//8D AFBLAwQUAAYACAAAACEA3tNaHWwHAADwOgAADwAAAHdvcmQvc3R5bGVzLnhtbLRb31PbOBB+v5n7 Hzx+p0Bok5Zp2qH8uDLTUtrA3LNiK0RTx8rZSoH+9bda2cKxcbyLXV7AsrTfrnb3WyVo3398WCXB L5nlSqfT8PDVQRjINNKxSu+m4e3Nxd7bMMiNSGOR6FROw0eZhx8//P3X+/vj3DwmMg9AQJofZ9Nw acz6eH8/j5ZyJfJXei1TeLfQ2UoYeMzu9vVioSJ5pqPNSqZmf3RwMN7PZCIMgOdLtc7DQto9Rdq9 zuJ1piOZ56DtKnHyVkKl4QdQL9bRmVyITWJy+5hdZ8Vj8YS/LnRq8uD+WOSRUjegOJi4UqnOPp+k uQrhjRS5OcmVqL48L8bs+6WdWH3pV0a5qQj8pGIV7lvQ/Dcs+yWSaTgalSOnVomtsUSkd+WYTPdu Z1VlpuHv5d7plR2ag9xpKLK92YkVto+Wlr8rFq+37IcnVGUtItg7ECMWRoIPwSVWaKKsr0eTcfnw Y5PAgNgYXYCgAACrioXH2qaDa8HRMxco8FYuvujop4xnBl5MQ8SCwdvL60zpTJnHafjuncWEwZlc qc8qjqWNy2LsNl2qWP67lOltLuOn8e8XGGWFxEhvUgPqjycYCEkenz9Ecm2jDESnwjr5yi5IrNi8 goMKbdSTNm6ghoqD/5WQh86Hz6IspbCZFKD+O4HQ6k1voJG1qGoAymXpetRfxOv+It70F4HB228v Jv21AP7s6xEXG5WopDvV6MgFX3Ufjt7tCFm7ohFFnSsaQdO5ohEjnSsaIdG5ohEBnSsaDu9c0fBv 54qGO3euiAQSVz2KjnA3SIl9o0wi7fqdBHTYk+qKUhNci0zcZWK9DGxtrau9iyxnm7mhqYp0+nKy nJlMp3edOwLV2abuizn5fLVeilzBoaZj60c9t/5GzBMZ/JOpuBPqjQu+hk14MHm2hF0nIpJLncQy C27kg/MoY/2VDmbulNGpXE+3flF3SxPMllhyO8HGLZvevhNO/heV4x7sTKZxiyldwkk+HLfEZbvw rzJWm1W5NYTTyNjxOcPNNQhUcfcWvbYuamZXpxXWARQTXLngm4DyCfq74sKXb31M0d+VohfKJ+jv CtcL5WN87PYvm2nORPYzIKXXhJ27pzrR2WKTlDnQSQ8TdgZ7CJoJ7CT28kkkMWFn8BZ9BidRBJ/c KHHK9sUTjzJQ2O5wKJhsdFvYTqnR3iHDIraDalgjBlY/rmUAsUn3h/yl7HdP3GKALO3Pmp3pfNSy A1CCSGfo7xttus/QoxbOo6JcpvB1SS4DGtpRS+ZR0Yp4cvWO4eN+hY8B1K8CMoD6lUIGUEt8tJ95 fE2kg/QvjgwsNi37KoZhR2bmCZuZPRCvBAxUNwnnr5bsbY+FZt0koLAd1KybBBS2d2q1zNdNAtZg dZOA1VI12n1U5VSOUey6WQXyJwGCRcOQNwFoGPImAA1D3gSg/uTdDTIceROw2NzgObVK3gQgnML5 qO+BquRNAGJzg2O74jujsu6hlN0fbgcgbwIK20FN8iagsL3TRt4ELJzCiYQalqc6AtYw5E0AGoa8 CUDDkDcBaBjyJgANQ94EoP7k3Q0yHHkTsNjc4Dm1St4EIDY9eKAqeROAcAqHG54lb8z6P07eBBS2 g5rkTUBhe6dGqP6QSsBiO6iG5cmbgIVTOMFQYGFwc4wahrwJFg1D3gSgYcibADQMeROA+pN3N8hw 5E3AYnOD59QqeROA2PTggarkTQBic8Oz5I3J+MfJm4DCdlCTvAkobO/UCNXzHAGL7aAalidvAhbG S2/yJgDhlJcCcSwahrwJFg1D3gSgYcibANSfvLtBhiNvAhabGzynVsmbAMSmBw9UJW8CEJsbniVv zJE/Tt4EFLaDmuRNQGF7p0aonrwJWGwH1bA81RGwhiFvAhAGZm/yJgDhlBcAYRZx3DQMeRMsGoa8 CUD9ybsbZDjyJmCxucFzapW8CUBsevBAVfImALG5wd6zhfui5Ouphy1BQL1nUN5qIAOOWpxEBSwM /CEXMoNmJtl9O6QnYGkhA7ElPKgmftL6Z0C72H3UEiBkKDVPlMYr3Y94S6fSiHA02dFJcPPtNPjs GmAa6zCktm/eQPdQtV0I25Ns4xDoaR7X0LKzLm+WW2nQIGRbu4oWIGxFu4SGoKKtxy62fT4wEZuq imH8v22Bin9D21tczjmAn8nZ2XnR4IQim0pES9Aigl6pHUoUV+H97SS8CF9XqeW+PKr11KxRKlfc m386Xbl5W7c3YQj2sEVvY++I79AZ75Dv3L0Apzh/NxWEti1UqUtDf98KZ5t54hrR4I/L1LoCOv/w f2vO5fGDcGLh/alMkq8C29aMXrdPTeTCuLeHB1gna6Lm2hi9al+f4TVy1OQ5AbDFVWXcozWife/T zWouM+gD27H/V9rWF+xX2w5cdyPWudtnHmiPcU3d9XbdtpLKp5HVxYdvQymshE+vUbe5gIa8b7a/ rpFwzWCB23i4qD0VxxdvDs/HblbRq6gwPqx3p+EEWiZQQgQ9JtCUsBFJ0WQAo2Bs2Z1YJENpfv7h fwAAAP//AwBQSwMEFAAGAAgAAAAhAD/vujMgAQAAygIAABMACAFkb2NQcm9wcy9jdXN0b20ueG1s IKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtJK9bsMgFEb3Sn0HxE7AJE5iy3bU 2MncIe1aIYwdS/xYQNxaVd+9RGmsdujSKhvoXp3z3QvZ5k1JMAjrOqNzGM0IBEJzU3e6zeHTYY/W EDjPdM2k0SKHo3BwU9zfZY/W9ML6TjgQENrl8Oh9n2Ls+FEo5mahrEOlMVYxH662xaZpOi4qw09K aI8pIUvMT84bhfoJBy+8dPB/RdaGn9O558PYh7hF9gUfQaN8V+fwvYrLqopJjOguKVFEoi1K5skK kTUhdEvLffKw+4CgPzdTCDRTYfQXK1httBwDcfCp7F+dt0WGv5+vpn8655OTH5luxe2Ni8nYnKRE 3Ghvjby9N756XSNZ+8MXLeJltKJkTX/bMT4/8+UTFp8AAAD//wMAUEsDBBQABgAIAAAAIQC98BLm +AEAAPsDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAJxTy27bMBC8F+g/CDo3ku0abmBQDAoHhQ9pY8BKcmaplUSUIgly7cb9+i6lWJbbnqrT vjQczg7Z3WunkyP4oKwp0nk2SxMw0lbKNEX6VH65uU2TgMJUQlsDRXqCkN7x9+/YzlsHHhWEhCBM KNIW0a3zPMgWOhEyahvq1NZ3Ain1TW7rWkm4t/LQgcF8MZutcnhFMBVUN24ETAfE9RH/F7SyMvIL z+XJEWHOSuicFgj8W6Sjs8pix/KxykqLQpeqAz6j8piwnWgg8DnLh4C9WF8FvljR1BCyTSu8kEgK 8vnydsXySYF9dk4rKZDE5V+V9DbYGpPHXoYkArB8OsJImj3Ig1d4ikSmKXtQJlJZsHyIiJsXjReu DfxjJDhmbC+Fhg0JwGuhA7D8UmBbEHG5O6GIMTvi+ggSrU+C+kXrXaTJdxEgylakR+GVMEjyxbEh 6WPtAnpeKtSETb0h78Pp2DRWy6gizVJwPRiLAwdqXLPrTwiPNd0N/0F2PiXbcxioTuhMwvGMP1A3 tnPCnPj2IH6CSkqQrbHaNtHZG5t9eMAqo62+TcU1/AhPrrT30U5v+l4XJ554UdjunZBxc5+WtKaL OyYtticTQUXrPgNeCmxLu/A6nkr/mgaq88zfjei35+Etk1GyGX29wc41csn4yPhvAAAA//8DAFBL AwQUAAYACAAAACEAJsaXn0gBAAB5AgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnJJRT4MwFIXfTfwPpO/QAts0BFiiZk9bYuKMxremvWON tDRtHdu/t8CGLPrk4+05/e65t82XR1kHBzBWNKpAcURQAIo1XKiqQK/bVXiPAuuo4rRuFBToBBYt y9ubnOmMNQaeTaPBOAE28CRlM6YLtHdOZxhbtgdJbeQdyou7xkjqfGkqrCn7pBXghJAFluAop47i DhjqkYjOSM5GpP4ydQ/gDEMNEpSzOI5i/ON1YKT980KvTJxSuJP2M53jTtmcDeLoPloxGtu2jdq0 j+Hzx/h9s37pRw2F6nbFAJU5ZxkzQF1jyvVdOiezHE+OuvXV1LqN3/ROAH84ja7fSmc2cBDdG5Vp jqel79OPNTQDHvig2TDWRXlLH5+2K1QmJF6EJAmTZJuk2XyWEfLRhbq63wUfDuQ52r+JF0DZJ77+ LOU3AAAA//8DAFBLAwQUAAYACAAAACEAYIOaml4CAABKCAAAEgAAAHdvcmQvZm9udFRhYmxlLnht bLyVT47aMBTG95V6h8j7Tpw/QEATRiNalrMoM+raBAcsxXZkBzKcocveozfobdp79MV2Mh3ICCK1 TUQknu2X51++7/n27pkX3oEqzaRIUXCDkUdFJjdMbFP09Lj8kCBPV0RsSCEFTdGRanQ3f//utp7l UlTag/VCz1SKdlVVznxfZzvKib6RJRUwlkvFSQV/1daXec4y+lFme05F5YcYj31FC1LBu/WOlRq5 bPU12WqpNqWSGdUaiuWFzccJE2juqvPqmSAcql6Qgq0VMwMlEVLTAMYOpEgRDvESj+DZ3DGOmify mwzZjihNq24ituGccFYc26iumdZ2oGRVtmvjB6IYWRfUDmm2hYG9XuMUfcJwhcslspEgRTEE7hdd JISi7BW4OVEXgc8DhZk8ZkowNXkgAnncKlOnb7/PGYkV46u9JUSK6gHotBX/+v71549vbitnjAI8 hvQRDtrbTjxhlIxt+DUjsq+ky3sdIreR6AVRmCTLJuoiHaJgfAFRw9ZgvB7RI+NUew+09j5LTiyr c9GEACQC4cRGPNEg0SiT14hsgGjC+04i8LEXsLFJErcS6Yjg6QUiwMPmuZ7IQu4Vo6ph8oaFJsBi aizUWCkeRIPLDVWiRyA5e6YbGz81UC+LVi//lMUXaDZNd9S9JEaNSF9fdgMnRsGhDf8do7S2AFkE 7uWnRums09tLkj9WXS+L1ZGvZfEGhxE0ihB+E/BJCB6ZDOAw3B8tcrft/wxiQTicLqSXROOGkesU TccYdrwMJ9F/vOC46x0v7mhl0ysJQ/Ty8eLOGT3/DQAA//8DAFBLAwQUAAYACAAAACEAf7zbUToH AACPQQAAEgAAAHdvcmQvbnVtYmVyaW5nLnhtbOxczW7jNhC+F+g7BAJ8jK0/y7Kx3oXj2ECL7bZo U/SsyEosVD+GJNvNdV+mj9DH2lfokJQUKqJkkaJTF/ClqUkNqW84Q818HO6HT3+Fwc3BS1I/juaK NlSVGy9y440fPc+V3x/Wt7Zyk2ZOtHGCOPLmyouXKp8+fv/dh+Ms2oePXgIP3sAYUTo7QPc2y3az 0Sh1t17opMN450XQ+RQnoZPBz+R5FDrJn/vdrRuHOyfzH/3Az15GuqpaSj5MPFf2STTLh7gNfTeJ 0/gpQyKz+OnJd738TyGRdJmXSN7H7j70ogzPOEq8AN4hjtKtv0uL0ULR0QDithjk0AbiEAbFc8dd l9k2iXMEPYcBee1jnGx2Sex6aQqt96SzHFFT2+bOFYiGKCW6vEJ1zuJNQsePymGQebxZ/3LxhrB4 IzL3CA31CgR08RGMyXlMs8Rxsy/78Kby64fNXFHxI1Hqb6Dv4ATQslrZ6kSdKCMkHO6DzP/sHbzg 4WXnFc9sXx4Tf/MT6gtQH3k2C3dB8YRt3K3u9OWS9AQH1OHDHzQj/G+2C9y5sjbuFssF2CeaCVwh yQpxjciBH6zDsvFxHwReVo744P1Vdt2WrT+6xRiB95Q/vPslQTP4EQKJmsEdVRu/yNaJnrFDGpaK xhgdZ/nTCRFK1nGUpSDnpK7vz5WlE/gAHoHwnDRbpL7zAB4JCxT6UZys8jbUv12AXisSbppRz975 GzzO1o/gjTbekwMKzV8Czw4vAypDr04rUHtVoGqqU1VVDdwCvgcuh7YKrb9CY26F2qqgQuN94nvJ zRfvSCut2uqmoMdqE6fW9JrWxvK19u3r37x608e6mN7+ALNF3xLYXUtTq7bxmRUxIuyXuVkRQ5Nq Vt++/sOrIEM3xRT020v4GMPnoNQO1cCnGrNmO5fgccYUtiyEjnsLe+NI+TZVbe3vccS/aIO6DI8z LcGtv+pdRGvVNj6zgris+BJelMeNTcGtnHIwoh2qgU81k5pqLsHjLE1wr3776TqTx0FC8cagLsPj LFtwC696l4jHQQhFxb8olKJ+graoXygcJpETHQ5rC3VirKZ5QCocDluqpa6tRfnxg6lr4bBuq6u1 rtskJD9b6DsRNeKLjHx7pw78ka4paM3vtAuwIt1uWtp4rh86eTYHKQedYQ2MYWm8LTlWBg6FJoO/ YOI4oYQkDu1LuxhieF0r06ziSTorw93wbFNIw06IWJGrBMCmFMA2BBskr2QCRt3cgFnxqATAYxmA IY9uA4y7uQGzQkkJgC0ZgE0D9tPmFcbd3IBZoaEEwBMZgMcQrLYAxt3cgFkBnwTAthTAk9ZNa4y6 uQGzYjUJgKcyAFtm66aFuzsA5oy9dBL3UFSkbtmWZlo6+fCIxl6TsWEuxvaKjEIzaXjZCBVZJmDd 1qCFihSgOITJSCq/6plwXUlFwj7ypamsUAscI5PMmV1Jxbki1+OupCLa5xjnIldSEY6oBGj8K6k4 V1oP3K6kYoPHXUlFMY/7/5CKRi2wNSb6vWXrOR0oGtgurZW1mpLss3pEXA9s1x2PhFspIK1TckET OtxcI+epbi1s1aYoFRMIwIL46CWfvSzzkjJRqPBfOjd47QRRyGazajGldtcH0q9x6ERsRExGL/Gf t81lEzWCTiszRRxMsCHVCbq1IKRW8+xG2NHmqcuh385ndN0oORqSJILtbEbH5Nzaja5GoXUyujqF dhaj60ap0SskiSA7n9F1I80qkORQYGczOiYr1m50NZKrweg4SS6zFguY5tIwzPZ6OxwhNFTaTTVD XyxtZqVdNzKrdVO9xG++ACw//fwc4IrGt+da2nCQE4zQ03KyRdv7ucMaQoWeroisrFw7xOHAKKOA jihrtCSC3VojyRm9kcBYNszhwLw4pMTtz4B0OBhzg30bluJ1lrmuY5Fk46T5wroC2uHAujzAXSuY +fy1BDwc5NXY3Xco+FpVD6VwMiJzkSfnXWTAPBzY3Et9dtikOuc8ngy2TWAPB1Ne5KzMrO9uzRnb ELeni6csc3Wv21YORpTnuF9q1kpdve7qkOHXiqfW/91dAu5o4HqVoJUqPsWbHGdNdzOqJczF/Ytq a//C5hpDo15GmWVtC+h6p6V/mWWVfqzzPZdxleAU3dNoWPLO2VmlW2KEZcuBKHdJ4ynSqFEx71TS yKr/kq41kVM/VPsFL9JUr9ioN9keVye7LsPjTnFdjQqS53GsyjLptsPtcaeKxhoV804exypPk641 AY+r0XLv942rR8NQ2Qw6gf++Xh2o3CeATlwBjZkXEIcnEXVVESNUD1MMB7wNYoQ6YYrlVxUgV/wZ bp/DPV10bbeIlwsKrNbVIkWxUZQYRoal4BWpyRBC6mc5N0X29BiFIlJ6jEIRFD1GobL+HqNQeXSP Uai0tNMoDWZF1NtsVg1iRJ9MMcytNogRBTLFMKvVIEY0xhQrMl7saUSc/EMKH/8FAAD//wMAUEsB Ai0AFAAGAAgAAAAhAMkxPFmAAQAAIgYAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVz XS54bWxQSwECLQAUAAYACAAAACEAmVV+BQQBAADhAgAACwAAAAAAAAAAAAAAAAC5AwAAX3JlbHMv LnJlbHNQSwECLQAUAAYACAAAACEAs76LHQkBAAC2AwAAHAAAAAAAAAAAAAAAAADuBgAAd29yZC9f cmVscy9kb2N1bWVudC54bWwucmVsc1BLAQItABQABgAIAAAAIQC+EIbd2QgAAAg1AAARAAAAAAAA AAAAAAAAADkJAAB3b3JkL2RvY3VtZW50LnhtbFBLAQItABQABgAIAAAAIQCWta3ilgYAAFAbAAAV AAAAAAAAAAAAAAAAAEESAAB3b3JkL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAV/oK QRkKAABmKQAAEQAAAAAAAAAAAAAAAAAKGQAAd29yZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAA ACEAO+g4yDoBAAClAgAAFAAAAAAAAAAAAAAAAABSIwAAd29yZC93ZWJTZXR0aW5ncy54bWxQSwEC LQAUAAYACAAAACEA3tNaHWwHAADwOgAADwAAAAAAAAAAAAAAAAC+JAAAd29yZC9zdHlsZXMueG1s UEsBAi0AFAAGAAgAAAAhAD/vujMgAQAAygIAABMAAAAAAAAAAAAAAAAAVywAAGRvY1Byb3BzL2N1 c3RvbS54bWxQSwECLQAUAAYACAAAACEAvfAS5vgBAAD7AwAAEAAAAAAAAAAAAAAAAACwLgAAZG9j UHJvcHMvYXBwLnhtbFBLAQItABQABgAIAAAAIQAmxpefSAEAAHkCAAARAAAAAAAAAAAAAAAAAN4x AABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQBgg5qaXgIAAEoIAAASAAAAAAAAAAAA AAAAAF00AAB3b3JkL2ZvbnRUYWJsZS54bWxQSwECLQAUAAYACAAAACEAf7zbUToHAACPQQAAEgAA AAAAAAAAAAAAAADrNgAAd29yZC9udW1iZXJpbmcueG1sUEsFBgAAAAANAA0AQgMAAFU+AAAAAA== --_004_4A95BA014132FF49AE685FAB4B9F17F657DEE702dfweml701chm_-- From nobody Tue Feb 23 03:51:10 2016 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 EFBF81A891E for ; Tue, 23 Feb 2016 03:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.191 X-Spam-Level: X-Spam-Status: No, score=-1.191 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, T_DKIM_INVALID=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 eZgIC6cMs3Yw for ; Tue, 23 Feb 2016 03:51:06 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0091.outbound.protection.outlook.com [104.47.1.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA131A00CA for ; Tue, 23 Feb 2016 03:51:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8sUTW2UuQIvGAjjhIK2KyWqG1/q5H+1BGEo+oErfegk=; b=IrbG71V9RtKsG4SNi3k/Iy3W+ai2r0AGylBut2yXd1u4eTqZhk/GtuqUaDba0oI7pbTzXKvy5xgD1Wb2R+Z3tk/Y57KprSR0fxrGL3KwhRbjErTH/4yG9JI38gSLaOt/bS6vm7BUQ3Kuev5y5OdoOQAG2ZfVsvMNT+PY+puaeBk= Authentication-Results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.171.3.105) by HE1PR07MB1626.eurprd07.prod.outlook.com (10.166.124.22) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 23 Feb 2016 11:50:59 +0000 Message-ID: <006d01d16e2f$f6b60fa0$4001a8c0@gateway.2wire.net> From: t.petch To: , "Alvaro Retana (aretana)" , References: <20151006081045.66A82187E04@rfc-editor.org> <008901d169a6$cc3d1da0$4001a8c0@gateway.2wire.net> <6928_1455786507_56C58A0B_6928_729_1_53C29892C857584299CBF5D05346208A0F7CE538@OPEXCLILM21.corporate.adroot.infra.ftgroup> Date: Tue, 23 Feb 2016 11:46:47 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.171.3.105] X-ClientProxiedBy: DB5PR08CA0007.eurprd08.prod.outlook.com (25.163.102.145) To HE1PR07MB1626.eurprd07.prod.outlook.com (25.166.124.22) X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1626; 2:PW7easBx6RmgWYmyk2SNTD5Rl+iI8VL8GTsQclyCqm1FDtZg0JwOTNqWxMNhdq6MvP3Qa2Qj3ROGeP5u9LZh1plUw5u40MVMzHbkMnd2zWNz8h3+5CLF21TgzyVPBJFW6/pH2233jvzcTfBABsiDnw==; 3:JtpRT8SUkvoiOVX+eG0IpzlBjYGzasLCB/DPN8v1p69j1xohG/kX67hpkuCWXD/80k22Z3zZ+JXKXe7fqDftTLXdhGzRjjXUJCicB8xUiHfz7Y/24dQDllt8PdQCdmvr; 25:jCDGN0opbIb8Giok+9SIWXDkGW/rKtq4MPQQH73eb3NXnb9PeGP3id2f4h0gfhcpm7i6frohJCqmd3YaDVt/7gqWoPInW5UC1XB2bfFoxA8HPl8Y+3ua3RUiT1ZBicNdNm9zDXr6DGt3MfW5hjUboRvGYCyhHblfzQ+4h9gfYgc7Try/cikrzXoRf9hpp1eEAqKGIyyxbuZ9+WccH7otXIAxZejDr4ZJPQPB6KNDW6Uoru7asYt2nX+FGYk5PMJBgusvIz2TQs9fqXstJX2q3OsofMN1UCsqSyx/7IUETB6DFabop1Or8pEK7fF5GokKAkvePVbMi2IOyF4NB+rja2St0e8QDK/IED3eoHyixUk= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB1626; X-MS-Office365-Filtering-Correlation-Id: d851e457-14cf-4c23-ef7a-08d33c479967 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014)(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:HE1PR07MB1626; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1626; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1626; 4:hE936cywyVjewoJRcPHiGXYcN1t/BTYUp/SMAkYfXy2xSIqsCzrSNabBCr5z+hxumEzTLm5uppVdcxpSC5ax3Vq+10GZ32T6SMvzNSJk+japRr/bmG63N8c/wrUdNI0IaMx3tp2818UDIHizQoHHKM9L2nSseyL4ZJQ9faqaZkrAMJPSoaYAWyTisy++DPo4HFb5KmUJzG24gt7DR4CE0xHTOXytVQ58Qj61aUaV2febt/X4khI7nriD4dWlF5YLgXdIEXTMSxMc5gzIvHlCdCDuPYq3b/vNB9CSrzaed4bVpYc239r5U6dxQakxSPw0A22Mo5oB/nVc0gSVIqA0fnQtmoGUqBfa/TqkAO4SwoCOjHO+NDRBkQPBo7mHxBKN9i8oCLmw1C0vhlGsdWrWRfNHyZdrxe1nqmUYnkK1j4xWAUpgCZcEFudn0b990YV751H9pdOmnrgKKlvPmlfiEw== X-Forefront-PRVS: 08617F610C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(377454003)(13464003)(24454002)(479174004)(44736004)(50226001)(23756003)(14496001)(1456003)(92566002)(2870700001)(6116002)(15975445007)(44716002)(50466002)(33646002)(62236002)(77096005)(19580395003)(19580405001)(40100003)(5001770100001)(1720100001)(5890100001)(122386002)(15188155005)(16799955002)(76176999)(81686999)(81816999)(189998001)(5001960100002)(107886002)(42186005)(1556002)(87976001)(3846002)(61296003)(50986999)(84392002)(1096002)(116806002)(47776003)(2906002)(5008740100001)(586003)(93886004)(66066001)(5004730100002)(86362001)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1626; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR07MB1626; 23:bhlGR63/JULkcuXgfu6xRgYrQoo8enBANFwpbKA?= =?iso-8859-1?Q?GZdg9INs3txb6Lopa9lyvgYsa7fT9aJjv+L8gvBayaTsJCltqN49PmA8jh?= =?iso-8859-1?Q?/w/hHwlc2CGdAuafEvboNAv5uZjhTq/6AsNeY7v8j5QnEKotAVQvtO626r?= =?iso-8859-1?Q?N8n8XpaoRkCy4wwnF4Q2DcbFkFAuBFzHLZsMRBqigKcsoweMn7D/VXxMPB?= =?iso-8859-1?Q?dTh07KPX3AyMkEHcxN2kSaBUXlUD0Nf5tpQoli+g2wMxfREsoltOdOxsrP?= =?iso-8859-1?Q?pOWMliwebxl/7IhlBw4WhsJBNqltvMsSlJJQYov9zanZRetqTxmuUAdw2C?= =?iso-8859-1?Q?hUSwtVB3wEnGIeAKadBMVaHhGamplwc9SJZE5DVdEx7dhu6d5eOagKDKHe?= =?iso-8859-1?Q?QeWxrSqYNWS26Ai3CsP281GMjIpO7ZJgC7Vb75W7L21LJaHw1Bs5jtrgcZ?= =?iso-8859-1?Q?g4iltcPg06239JmKBtRXkvc+Y7MVnNmhUGwBgpsut7hTUad9dAEpb2VjXn?= =?iso-8859-1?Q?Y5E6dVj7GogyIm0aTWEwoYCyVwb9+4lP+netEowOtzY1EL3vxwh3XfUVM4?= =?iso-8859-1?Q?Ywuw1XUy4ym0521PnUl+lq4qaxXrCq941ay2K/oDAQlvWbU31YHl02AKFE?= =?iso-8859-1?Q?YfncUk6qssG9HBPH1aR7guyHB5LO9qusGljQofBO2Ygz66FgnNTfWwI53m?= =?iso-8859-1?Q?FjJ7S4Fb6VeqqaqqzpwsMBVi02S2YWeFltMphzZosdOb7WnxABebSgj7L7?= =?iso-8859-1?Q?XzaxNh+wuHWAd/yHOGHjOh1oaZA284DkWauh5C+5xrLBHw+205CVZttkWd?= =?iso-8859-1?Q?bXuqZhK4ZUS/GltuWy97NQLFFvA98eD868/jfHPZb8yQijRvWmfaf5SYUO?= =?iso-8859-1?Q?uALcC0p6I1QzLPawAsWtuylH4o0c4AuOaJ41YU2KNux3yecsQSp7LIeApQ?= =?iso-8859-1?Q?m1JY9/44aMWiE8IChaqXIY5G9OzFjehhI2UgI6FN0ueQV/V0SROAcof2Lz?= =?iso-8859-1?Q?9P09SsLXi8v6Mv3LEA4vXynq2okKoVt1qU9KQfdXSYtzB+E6RuO0CKHQub?= =?iso-8859-1?Q?iqK2AswUz7z/ANES/EiTOnCMxJ+u9DpARQPLRAamvwftHRaFlMLK66aoMJ?= =?iso-8859-1?Q?zSRh0u72aSMzNqpf4vYhlJBLheiYfwCHTnsG26yNA2xUU8JB+GjBKLtQkn?= =?iso-8859-1?Q?QtjMcjdDko1SAv1oqE7ZdusybxMOJC5Kppk1MEQH1Yl6awNhdsRyTqnG85?= =?iso-8859-1?Q?AD8qXWaLkS6CeARZok/BRzt6p5WpWKTb/Hz40PuyoBjHgESll5Jyiq8hcH?= =?iso-8859-1?Q?aMmapE8O23fHDMFLtJraDzsxJujtxw+oJFx5QwYcom7E4eIyr3W0LqpKI9?= =?iso-8859-1?Q?TJF8Al9Hts3CoNDpA+N86+GT7eTEGkmJPbAErGgQHdU0DePmcsRxmkexhe?= =?iso-8859-1?Q?/spuCqxzVzllOku2Gw0wE/kZmDrG/WFmc9BT1SS/ldRLL9UXI7RaJu0qg?= =?iso-8859-1?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1626; 5:um0pXU/PXMa7TK5YrueivPqjVg282EwGvP0s7hkVcOCnEPX0TmjbELJNiCNPhyXaXly0emKHUn5fZuuLs2VOC1LJwsFolgcCnTFm2U6EPJLubrvgMi4swTiMmc4a0k0Q3KMoQ5VTECO4bFD1byL02Q==; 24:T/g58bDLB1OTsBs/lKfjwaSuesCCC5bZpnnhomtJqV1XhKLNjAAsbdpICKi09efFpH6xyuBHDReK1nljtkslNjlqbd4FwQE6Ys7JGfPvwJA= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2016 11:50:59.7348 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1626 Archived-At: Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (4493) 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, 23 Feb 2016 11:51:09 -0000 Tom Petch ----- Original Message ----- From: To: "t.petch" ; "Alvaro Retana (aretana)" ; Sent: Thursday, February 18, 2016 9:08 Hi Tom, Please see inline > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Wednesday, February 17, 2016 6:15 PM > > ----- Original Message ----- > From: "Alvaro Retana (aretana)" > To: > Cc: > Sent: Wednesday, February 17, 2016 3:08 PM > > Idr WG: > > Please take a look at the Errata below. I need your opinion on it. > > I'm leaning towards rejecting it because I interpret "Unspecific" not as > the name of the subcode, but as just an indication that the error is not > specific. The IANA registry [1] lists the value 0 as "Reserved", which > I > think is ok according to the definition in RFC5226: > > > > Reject. > > s.6.2 specifies a specific(!) instance of using 0(Unspecific) (so I > think that IANA is in error here). Arguably, you could raise an erratum > to add 0(Unspecific) for the OPEN Message Error subcodes list Agreed. > but I > think that it would be a technical change to add it for the other > messages. As currently defined, it could be seen as an implementation > error were subcode 0 be used for the other messages (an interpretation > which I have no problem with). I don't think you can call "implementation error" a behavior which is specified in the RFC: "If no appropriate Error Subcode is defined, then a zero (Unspecific) value is used for the Error Subcode field." https://tools.ietf.org/html/rfc4271#section-4.5 This sentence is generic and applies to all error codes. Ah yes, my mistake. On balance, I would still support an Erratum that updates "OPEN Message Error subcodes:" but would see updating all the lists of subcodes as going too far. A zero subcode for any other message is not something that the IDR WG could think of a reason for, unlike the case of OPEN, so while calling it an error is wrong, it remains something unusual, unexpected. Adding it to all the lists of subcodes would seem to go beyond what the IDR WG consented to when it produced RFC4271. Tom Petch Accepting the errata or not is a different story. -- Bruno > If there are errors that cannot be reported using the subcodes in > RC4271, then that is a separate issue that could be worth investigating. > > Tom Petch > > > Reserved: Not to be assigned. Reserved values are held for > special uses, such as to extend the namespace when it become > exhausted. Reserved values are not available for general > assignment. > > In this case the "special use" is when the error is not specific. > > Any thoughts? Other opinions? > > Thanks! > > Alvaro. > > [1] > http://www.iana.org/assignments/bgp-parameters/bgp- > parameters.xhtml#bgp- > par > ameters-4 > > On 10/6/15, 4:10 AM, "RFC Errata System" > wrote: > > >The following errata report has been submitted for RFC4271, > >"A Border Gateway Protocol 4 (BGP-4)". > > > >-------------------------------------- > >You may review the report below and at: > >http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=4493 > > > >-------------------------------------- > >Type: Technical > >Reported by: Bruno Decraene > > > >Section: 4.5 > > > >Original Text > >------------- > >§\\"4.5 NOTIFICATION Message Format\\" says: > > > > Message Header Error subcodes: > > > > 1 - Connection Not Synchronized. > > 2 - Bad Message Length. > > 3 - Bad Message Type. > > > > OPEN Message Error subcodes: > > > > 1 - Unsupported Version Number. > > 2 - Bad Peer AS. > > 3 - Bad BGP Identifier. > > 4 - Unsupported Optional Parameter. > > 5 - [Deprecated - see Appendix A]. > > 6 - Unacceptable Hold Time. > > > > UPDATE Message Error subcodes: > > > > 1 - Malformed Attribute List. > > 2 - Unrecognized Well-known Attribute. > > 3 - Missing Well-known Attribute. > > 4 - Attribute Flags Error. > > 5 - Attribute Length Error. > > 6 - Invalid ORIGIN Attribute. > > 7 - [Deprecated - see Appendix A]. > > 8 - Invalid NEXT_HOP Attribute. > > 9 - Optional Attribute Error. > > 10 - Invalid Network Field. > > 11 - Malformed AS_PATH. > > > >Corrected Text > >-------------- > > Message Header Error subcodes: > > > > 0 - Unspecific. > > 1 - Connection Not Synchronized. > > 2 - Bad Message Length. > > 3 - Bad Message Type. > > > > OPEN Message Error subcodes: > > > > 0 - Unspecific. > > 1 - Unsupported Version Number. > > 2 - Bad Peer AS. > > 3 - Bad BGP Identifier. > > 4 - Unsupported Optional Parameter. > > 5 - [Deprecated - see Appendix A]. > > 6 - Unacceptable Hold Time. > > > > UPDATE Message Error subcodes: > > > > 0 - Unspecific. > > 1 - Malformed Attribute List. > > 2 - Unrecognized Well-known Attribute. > > 3 - Missing Well-known Attribute. > > 4 - Attribute Flags Error. > > 5 - Attribute Length Error. > > 6 - Invalid ORIGIN Attribute. > > 7 - [Deprecated - see Appendix A]. > > 8 - Invalid NEXT_HOP Attribute. > > 9 - Optional Attribute Error. > > 10 - Invalid Network Field. > > 11 - Malformed AS_PATH. > > > >Notes > >----- > >RFC 4271 defines a use and a name for Error subcode 0: > >- §4.5 (any error code): > > If no appropriate Error Subcode is defined, then a zero > > (Unspecific) value is used for the Error Subcode field. > > > >- §6.2 (OPEN error code): > > If one of the Optional Parameters in the OPEN message is recognized, > > but is malformed, then the Error Subcode MUST be set to 0 > > (Unspecific). > > > >If verified, the \\"IANA Considerations\\" section and the IANA > registry > >would also need to be updated accordingly (currently says \\"0 > >Reserved\\") > >http://www.iana.org/assignments/bgp-parameters/bgp- > parameters.xhtml#bgp > -pa > >rameters-4 > > > >Instructions: > >------------- > >This erratum is currently posted as "Reported". If necessary, please > >use "Reply All" to discuss whether it should be verified or > >rejected. When a decision is reached, the verifying party (IESG) > >can log in to change the status and edit the report, if necessary. > > > >-------------------------------------- > >RFC4271 (draft-ietf-idr-bgp4-26) > >-------------------------------------- > >Title : A Border Gateway Protocol 4 (BGP-4) > >Publication Date : January 2006 > >Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. > >Category : DRAFT STANDARD > >Source : Inter-Domain Routing > >Area : Routing > >Stream : IETF > >Verifying Party : IESG > > > > _______________________________________________ > 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 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 been modified, changed or falsified. Thank you. From nobody Tue Feb 23 06:08:41 2016 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 B38791B2E6C for ; Tue, 23 Feb 2016 06:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 vPR49H6oXaQK for ; Tue, 23 Feb 2016 06:08:37 -0800 (PST) Received: from atl4mhob02.myregisteredsite.com (atl4mhob02.myregisteredsite.com [209.17.115.40]) by ietfa.amsl.com (Postfix) with ESMTP id EC2821B2E5A for ; Tue, 23 Feb 2016 06:08:35 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.207]) by atl4mhob02.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u1NE8Yr4016574 for ; Tue, 23 Feb 2016 09:08:34 -0500 Received: (qmail 13907 invoked by uid 0); 23 Feb 2016 14:08:33 -0000 X-TCPREMOTEIP: 65.189.201.79 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.104?) (wes@mti-systems.com@65.189.201.79) by 0 with ESMTPA; 23 Feb 2016 14:08:33 -0000 To: Linda Dunbar , Justin Dailey , "idr@ietf.org" References: <4A95BA014132FF49AE685FAB4B9F17F657DEA4A3@dfweml701-chm> <56CB701F.5010500@mti-systems.com> <4A95BA014132FF49AE685FAB4B9F17F657DEE702@dfweml701-chm> From: Wesley Eddy Message-ID: <56CC67DA.5000009@mti-systems.com> Date: Tue, 23 Feb 2016 09:08:26 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657DEE702@dfweml701-chm> Content-Type: multipart/alternative; boundary="------------030800020808040800050405" Archived-At: Subject: Re: [Idr] more suggestions to draft-eddy-idr-flowspec-exp-00 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, 23 Feb 2016 14:08:39 -0000 This is a multi-part message in MIME format. --------------030800020808040800050405 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Linda, some replies are inline below: On 2/22/2016 7:01 PM, Linda Dunbar wrote: > Wes, > Thank you very much for the reply. Since my writing to you a week ago, > I’ve done some study of other IDR FlowSpec related drafts (there are > many of them). > I think it is worthwhile to look at all flow Spec approach > holistically like > https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/ I agree completely with this, and think that a "flowspec v2" such as that draft proposes is probably a good idea, given the mass of modifications people are proposing. > First of all, I believe that Flow Spec is very useful for influencing > routes (as described by the Section 3 of > https://datatracker.ietf.org/doc/draft-li-idr-flowspec-rpd/ ). It is > great to see many extensions to make IDR FlowSpec more comprehensive. > However, Flow Spec is far from enough for mitigating today’s > sophisticated DDoS attacks. As in Amazon’s AWS service where attackers > are from leased virtual machines, more and more DDoS attacks do > originate from legitimate sources (i.e. the approach described by > RFC5635 has more chance of dropping legitimate traffic than the DDoS > attack packets) . This seems to me like yet more rationale for interdomain communication that allows the abuse to be notified and appropriate filters to be applied as close to the source as possible. The "collateral damage" effect of over-broad filtering can enable new attack vectors, designed to cause some third-party target to fall within the same filter specification as a dummy attack. > Therefore, IMHO, the “Introduction section” of your draft shouldn’t > focus on what Flow Spec is missing when used for Anti-DDoS, because > there are a lot more missing. The “extension” you described is not > enough in mitigating the modern DDoS attacks. There is a working Group > DOTS whose purpose is for DDoS mitigation. The scope of DOTS is significantly different, IMO. I think it is complementary work and not at odds with flowspec and flowsepc enhancements. > Instead the “Introduction” should describe the general structure of > IDR FlowSpec, to make RFC5575 more complete in influencing routes. > For example, I think the following items should be described for Flow > Specs: > > * Flow Specs consists of two major components: Matching criteria and > Actions. The Matching criteria are carried by NRLI, the Actions > are carried by BGP extended Community. > > * For Actions: there are two major categories (*Separating Control > Plane policy from the data plane policy *) > > * Data Plane action: The Actions for local node, i.e. ACL actions to > routers, such as Rate Limiting, forwarding, egress, tunnel, etc > * Control Plane action: The Actions for how the routes is propagated > to peers and its priority (or the precedence) if conflicting with > other routes. > > * Your draft is to describe the extension of Matching Criteria & > Actions for Packet Rate action, the Tunnel Description, Flow Spec > identifier, etc. > > Attached is my suggested wording for the introduction of your draft. Thanks! We'll consider this when updating the draft. I'm not actually sure if it will be updated, or needs to be updated at the moment, as it was really just to generate discussion and describe some ideas (not all of which are very practical). For instance, the tunnel specification has some real problems. We did already split out the description of the packet rate action into draft-eddy-idr-packet-rate, since it seemed immediately practical and relatively trivial. I think in Sue's omnibus draft that you cited above, she did a good job of pulling out the couple pieces that are applicable in the near-term, and I believe the other topics that we discussed in draft-eddy-idr-flowspec-exp are still just interesting research topics that are pretty far from being ready to consider for standardization. --------------030800020808040800050405 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Linda, some replies are inline below:

On 2/22/2016 7:01 PM, Linda Dunbar wrote:
Wes,
 
Thank you very much for the reply. Since my writing to you a week ago, I’ve done some study of other IDR FlowSpec related drafts (there are many of them).
 
I think it is worthwhile to look at all flow Spec approach holistically like https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/
 

I agree completely with this, and think that a "flowspec v2" such as that draft proposes is probably a good idea, given the mass of modifications people are proposing.
First of all, I believe that Flow Spec is very useful for influencing routes (as described by the Section 3 of https://datatracker.ietf.org/doc/draft-li-idr-flowspec-rpd/ ). It is great to see many extensions to make IDR FlowSpec more comprehensive.
 
However, Flow Spec is far from enough for mitigating today’s sophisticated DDoS attacks. As in Amazon’s AWS service where attackers are from leased virtual machines, more and more DDoS attacks do originate from legitimate sources (i.e. the approach described by RFC5635 has more chance of dropping legitimate traffic than the DDoS attack packets) .
 

This seems to me like yet more rationale for interdomain communication that allows the abuse to be notified and appropriate filters to be applied as close to the source as possible.

The "collateral damage" effect of over-broad filtering can enable new attack vectors, designed to cause some third-party target to fall within the same filter specification as a dummy attack.
Therefore, IMHO, the “Introduction section” of your draft shouldn’t focus on what Flow Spec is missing when used for Anti-DDoS, because there are a lot more missing. The “extension” you described is not enough in mitigating the modern DDoS attacks. There is a working Group DOTS whose purpose is for DDoS mitigation.

The scope of DOTS is significantly different, IMO.  I think it is complementary work and not at odds with flowspec and flowsepc enhancements.
 
Instead the “Introduction” should describe the general structure of IDR FlowSpec, to make RFC5575 more complete in influencing routes.
 
For example, I think the following items should be described for Flow Specs:
 
  • Flow Specs consists of two major components: Matching criteria and Actions. The Matching criteria are carried by NRLI, the Actions are carried by BGP extended Community.
  • For Actions: there are two major categories (Separating Control Plane policy from the data plane policy )
    •
  • Data Plane action: The Actions for local node, i.e. ACL actions to routers, such as Rate Limiting, forwarding, egress, tunnel, etc
  • Control Plane action: The Actions for how the routes is propagated to peers and its priority (or the precedence) if conflicting with other routes.
 
  • Your draft is to describe the extension of Matching Criteria & Actions for Packet Rate action, the Tunnel Description, Flow Spec identifier, etc. 
 
Attached is my suggested wording for the introduction of your draft.
 

Thanks!  We'll consider this when updating the draft.  I'm not actually sure if it will be updated, or needs to be updated at the moment, as it was really just to generate discussion and describe some ideas (not all of which are very practical).   For instance, the tunnel specification has some real problems.  We did already split out the description of the packet rate action into draft-eddy-idr-packet-rate, since it seemed immediately practical and relatively trivial.

I think in Sue's omnibus draft that you cited above, she did a good job of pulling out the couple pieces that are applicable in the near-term, and I believe the other topics that we discussed in draft-eddy-idr-flowspec-exp are still just interesting research topics that are pretty far from being ready to consider for standardization.



 --------------030800020808040800050405-- From nobody Sun Feb 28 18:56:41 2016 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 06D071B2A99; Sun, 28 Feb 2016 18:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.607 X-Spam-Level: X-Spam-Status: No, score=-12.607 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qUIzoncydH4; Sun, 28 Feb 2016 18:56:35 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 506EF1B2A7F; Sun, 28 Feb 2016 18:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30474; q=dns/txt; s=iport; t=1456714595; x=1457924195; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=I8vNS30nd/2Hx6oZLBE8B1ivEGKMaNhh/3Td3NrUKlk=; b=bz4W85kcRISc4qpiYO0Hd3EGAVxZh35VVFxz8WoingkDbrGMJ8Z9WRu+ SkKsODsoYiqdW/2Kr3xgZqSvBD5rv+mgCWKLbqVuycvf6ZBilmbzGJDut NYTZmYRL98vaXk6QGh+nI4L8Fia1tMUafcVyErAOgJo2CFk/jSWnHdGvH U=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CzAgCWstNW/4QNJK1egzpSbQa6Vg6BZ?= =?us-ascii?q?iOFcAKBJjgUAQEBAQEBAWQnhEEBAQEDARoJVgULAgEIGCAKAgIyJQIEDgUJBYg?= =?us-ascii?q?JCA6vW44rAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiGEoFsgk6ED1OCUyuBDwWHU?= =?us-ascii?q?IslhBcBgwiBZGyCb4UagV6ERIhShXMWiEABHgFDggMZgUhqAQEBhwU9fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,518,1449532800"; d="asc'?scan'208,217";a="243570621" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Feb 2016 02:56:33 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u1T2uXJM023432 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Feb 2016 02:56:33 GMT Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 28 Feb 2016 20:56:32 -0600 Received: from xch-aln-020.cisco.com ([173.36.7.30]) by XCH-ALN-020.cisco.com ([173.36.7.30]) with mapi id 15.00.1104.009; Sun, 28 Feb 2016 20:56:33 -0600 From: "Carlos Pignataro (cpignata)" To: Eric C Rosen Thread-Topic: [bess] I-D Action: draft-ietf-idr-tunnel-encaps-01.txt Thread-Index: AQHRQYNgm76iX7yesESh/1GkNtrtOp8oG2EAgAXw9YCAFQ7OAA== Date: Mon, 29 Feb 2016 02:56:32 +0000 Message-ID: <8A075A71-4B7F-4A8A-893D-596ED436E384@cisco.com> References: <20151221171512.15817.2209.idtracker@ietfa.amsl.com> <56815342.7030609@juniper.net> <56C2093D.7080800@juniper.net> In-Reply-To: <56C2093D.7080800@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.255.113] Content-Type: multipart/signed; boundary="Apple-Mail=_0B18B767-0822-4372-8C6B-45EDC44516EF"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "bess@ietf.org" Subject: Re: [Idr] [bess] I-D Action: draft-ietf-idr-tunnel-encaps-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: Mon, 29 Feb 2016 02:56:40 -0000 --Apple-Mail=_0B18B767-0822-4372-8C6B-45EDC44516EF Content-Type: multipart/alternative; boundary="Apple-Mail=_2B05E73D-B176-45F5-B753-0C8C69FC1C2F" --Apple-Mail=_2B05E73D-B176-45F5-B753-0C8C69FC1C2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Eric, Thanks for the response =E2=80=94 please find some follow-ups inline. > On Feb 15, 2016, at 12:22 PM, Eric C Rosen wrote: >=20 > On 2/11/2016 6:38 PM, Carlos Pignataro (cpignata) wrote: >> Hi, Eric, >>=20 >> Thanks for sending this out =E2=80=94 I am interested in this = document, and will give it a critical review (in particular the sections = you call out below). > Thanks! >>=20 >> In the mean time, however, I wanted to send a few high-level comments = (prepended with =E2=80=9CCMP=E2=80=9D) from scanning through it. I hope = these are useful. >>=20 >> 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types >>=20 >> This section defines Tunnel Encapsulation sub-TLVs for the = following >> tunnel types: VXLAN ([RFC7348]), VXLAN-GPE ([VXLAN-GPE]), NVGRE >> ([RFC7637]), GTP ([GTP-U]), MPLS-in-GRE ([RFC2784], [RFC2890], >> [RFC4023]), L2TPv3 ([RFC3931]), and GRE ([RFC2784], [RFC2890], >> [RFC4023]). >>=20 >>=20 >> CMP: More comments below, but I am a bit confused about the need to = include MPLS-in-GRE, and the lack of IP-in-IP (Tunnel Type 7) for = example. > MPLS-in-GRE is included in section 3.2 because there is already a = tunnel type codepoint allocated for it, and if that tunnel type is used, = an encapsulation sub-TLV is needed in order to signal the GRE key. >=20 > One can argue that there is no need for the MPLS-in-GRE tunnel type, = since everything you can do with it could be done instead with the GRE = tunnel type. But unless and until we decide to deprecate the = MPLS-in-GRE tunnel type, it needs to be included. In theory, I would = love to see the MPLS-in-GRE tunnel type deprecated, but I worry that = that might introduce a backwards compatibility problem. This is = certainly something that can be discussed by the WG. >=20 I agree =E2=80=94 and would welcome that discussion as well. > IP-in-IP is not mentioned in section 3.2 because, although there is a = tunnel type codepoint allocated for it, no one has ever defined an = encapsulation sub-TLV for it. Also, if it is necessary to signal values = for the fields of the outer iP header, it might make more sense to use = an "outer encapsulation sub-TLV" (section 3.3). Do you have an opinion = about this? You are right, Section 3.2 is indeed about the sub-TLVs. I believe I was = reacting to IP-in-IP not being mentioned anywhere (other than briefly in = the IANA section). Perhaps I was expecting something like this, although I agree with you = it=E2=80=99s a no-op: 3.2.x. IP-in-IP This document does not defines an encapsulation sub-TLV for IP-in-IP = tunnels. When the tunnel type is IP-in-IP, the encapsulation sub-TLV MUST NOT = be used. Now, IP-in-IP and other tunnels (like for example MPLS-over-UDP) present = an interesting question (that you raise above): In these, is the = encapsulation IP and UDP, or is this a null encapsulation with an outer = encapsulation of IP and UDP? To me, the pragmatic case is to use the Outer encapsulation sub-TLV for = IP fields in IP-in-IP, and for UDP fields in MPLS-over-UDP. However, if the Tunnel Type is IP-in-IP (7), then using an = Outer-encapsulation sub-TLV would imply IP-in-IP-in-IP. Is IP-in-IP a = null tunnel type with outer encapsulation and with protocol =3D 0x0800? = No. It is an IP-in-IP tunnel type. No protocol (since the tunnel encap = constraints it to IP), and no outer encap. It is not =E2=80=9Cfurther = encapsulated inside UDP and/or IP=E2=80=9D as the text in section 1.3 It would certainly help to explain this explicitly. It gets equally interesting with MPLS-over-UDP, because =E2=80=9CUDP=E2=80= =9D is not a tunnel type specified just yet, which could be used with = MPLS protocol type sub-TLV. Or a more limiting and duplicative = MPLS-in-UDP tunnel type. What tunnel type is used there? null encap? = protocol type sub-TLV? One additional comment =E2=80=94 I could not figure out the sorting = order for the encapsulations in subsections 3.2.x. I would consider = sorting by tunnel type value in ascending order, and starting each = sub-section with a =E2=80=9CThis encapsulation sub-TLV is used when the = Tunnel Type is XYZ (numerical value)" >>=20 >> CMP: A couple of editorial comments as well: For GRE, I think you = also need to cite RFC 7676 (GRE over IPv6) > Sure. Thank you. >>=20 >> CMP: Also, having this document Obsolete RFC 5512 effectively also = orphans a number of Tunnel types and sub-TLVs. For example, Tunnel Types = values 3-6 from RFC 5566 (IPsec Tunnel Encap) and IPsec Tunnel = Authenticator sub-TLV. I do not know if the answer is to also have that = incorporated (useful parts as you say) and obsoleted. Maybe not, maybe = it does make sense given it is a short doc, which would lead to a = complete self-contained set of Tunnel types. > I think RFC 5566 will have to be obsoleted and replaced. I've been = thinking about that, but I'm still not sure how much of 5566 should be = moved into the tunnel-encaps draft and how much should be in a separate = draft. There are some non-obvious issues to consider. For example, = 5566 really is just intended to facilitate iPsec Security Associations = between BGP Next Hops, but with the tunnel encapsulation attribute we = could presumably set up Security Associations from ingress to egress. Indeed. Thank you =E2=80=94 the goal would be that 5566 does not get = completely out-of-sync. >>=20 >> 3.2.4. L2TPv3 I forgot to mention, the way in which the encapsulation sub-TLV is = defined, this specifies only encapsulation for L2TPv3 directly over IP. = This section, as well as all references to it, should be =E2=80=9CL2TPv3 = over IP=E2=80=9D (like the tunnel type is named now) = http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel= -types = L2TPv3 can run: * over IP: https://tools.ietf.org/html/rfc3931#section-4.1.1.1 = * over UDP: https://tools.ietf.org/html/rfc3931#section-4.1.2.1 = And L2TPv3 over UDP has a slightly different encap header, so using the = outer encap sub-TLV is not the way to define L2TPv3 over UDP. = Consequently, I=E2=80=99d explicitly say =E2=80=9CL2TPv3 over IP=E2=80=9D = everywhere. >> =E2=80=A6 >> Cookie: an optional, variable length (encoded in octets -- 0 to = 8 >> octets) value used by L2TPv3 to check the association of a >>=20 >> CMP: The cookie can only take sizes 0, 4, or 8 octets, and not 0..8 > Do you have a reference for that? Section 4.1 of RFC 3931 seems to = say only that the field is variable length with a maximum size of 64 = bits. Yes, RFC 3931, when defining the Assigned Cookie: = https://tools.ietf.org/html/rfc3931#page-50 = as well as the 4th = paragraph of S8.2 of RFC 3931. >>=20 >> 3.2.7. MPLS-in-GRE >>=20 >> CMP: This seems to be an example and not a separate encapsulation = type. This is GRE Type, with MPLS as protocol sub-TLV. I see that the = section says: >>=20 >> While it is not really necessary to have both the GRE and = MPLS-in-GRE >> tunnel types, both are included for reasons of backwards >> compatibility. >>=20 >> CMP: I will also note that having two different ways of doing the = same thing (Tunnel Type 2 and protocol 0x8847 vs. Tunnel Type 11) takes = us away from interop., and that there does not seem to be MPLS-in-GRE = defined in any RFC (so it seems like potentially a good time to = rationalize instead of perpetuate). My $0.02 only. > Tunnel type 11 is used by draft-ietf-bess-evpn-overlay. >>=20 >> CMP: Should MPLS-over-GRE be an example only? Or otherwise, how do we = interop the two types of =E2=80=9C MPLS-over-GRE=E2=80=9D? > Well, the two ways of doing the same thing are explicitly defined to = be equivalent, so I don't think there is an interop issue, the issue is = more of "can we get rid of the MPLS-in-GRE type without causing a = backwards compatibility problem=E2=80=9D. Sorry, what I meant was if an endpoint understands one way, and the = other endpoint the other way only. I do not disagree with what you write, but an explicit statement would = not hurt (and may help) >> Should an example be also added about MPLS-over-L3TPv3? > Surely no one will ever propose MPLS-over-L2TPv3 again! I meant it in the sense of why a special case for MPLS-over-GRE as its = own type. >>=20 >> 3.3.1. IPv4 DS Field >>=20 >> CMP: Why not also define this for IPv6? > There are a lot of possible Outer Encapsulation sub-TLVs that could be = created, I only included a couple of examples that seemed like they = might be useful. If you have some sub-TLVs to suggest for the case = where the outer encapsulation is IPv6, please suggest some text. (Some = IPv6-specific text will probably make it easier to get the draft past = the IESG ;-)) Sorry I was not clear =E2=80=94 this is what I meant: Section 3.3.1 is defining a DS field based on RFC 2474. RFC 2474 in turn = defines the DS field for the IPv4 TOS and the IPv6 TC octets. Therefore, why would this sub-section be suddenly limited to IPv4, when = 2474 applies to both IPv4 and IPv6? In other words, why not: =E2=80=9C3.3.1. IP DS Field=E2=80=9D? [I did not mean let=E2=80=99s have some IPv6-specific sub-TLVs] I have been thinking about the Flow Label advertisement for IPv6, but = I=E2=80=99m still thinking about it :-) Lastly, this reminds me of a very small nit: Sections 3.6 (and others?) = refers to the MPLS ToS field, when that=E2=80=99s been renamed to the TC = field https://tools.ietf.org/html/rfc5462 = . >>=20 >> 3.3.2. UDP Destination Port >>=20 >> CMP: One additional thought. Obsoleting RFC 5512 also removes the = anchor from RFC 5640 =E2=80=94 that is not a terrible deal in itself, = but is there also an opportunity to generalize the Load-Balancing = approach thereby defined to also include the new encapsulations=E2=80=99 = LB, UDP-based (port as the LB Field), etc? > I wasn't aware of RFC 5640. >=20 > I don't think there's anything in RFC 5640 that requires the = Encapsulation-SAFI. So at a minimum, I think we can get by with saying = that the tunnel-encaps draft updates RFC 5640, and that the LB Block = sub-TLV can be included in the a tunnel TLV of a tunnel encapsulation = attribute that is attached to an update of any AFI/SAFI. Exactly. >=20 > If you think it is worthwhile to generalize the load balancing = approach of RFC 5640, perhaps the best approach would be to do a = 5640bis. If you don=E2=80=99t disagree, I think saying what you described two = paragraphs above would really help (and most likely be sufficient). >=20 >>=20 >> I hope these are clear and useful =E2=80=94 Thanks! >>=20 > Looking forward to any additional comments you might have! Apologies for the delay in sending these out as well as with this = follow-up. One additional small request =E2=80=94 in Section 12.5, could we please = reserve a couple of values for experiments? =E2=80=9C IANA is requested to assign two codepoints from the "BGP Tunnel Encapsulation Tunnel Types" registry for experimentation. The values 65534 and 65535 are recommended for experimental use. =E2=80=9C Thanks! =E2=80=94 Carlos. --Apple-Mail=_2B05E73D-B176-45F5-B753-0C8C69FC1C2F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Eric,

Thanks for the response =E2=80=94 please find some follow-ups = inline.

On Feb 15, 2016, at 12:22 PM, = Eric C Rosen <erosen@juniper.net> wrote:

On = 2/11/2016 6:38 PM, Carlos Pignataro (cpignata) wrote:
Hi, Eric,

Thanks for sending this out =E2=80=94 I am = interested in this document, and will give it a critical review (in = particular the sections you call out below).
Thanks!

In the mean time, however, I wanted to send a = few high-level comments (prepended with =E2=80=9CCMP=E2=80=9D) from = scanning through it. I hope these are useful.

3.2.  Encapsulation Sub-TLVs for Particular Tunnel = Types

   This section = defines Tunnel Encapsulation sub-TLVs for the following
=    tunnel types: VXLAN ([RFC7348]), VXLAN-GPE = ([VXLAN-GPE]), NVGRE
   ([RFC7637]), GTP = ([GTP-U]), MPLS-in-GRE ([RFC2784], [RFC2890],
=    [RFC4023]), L2TPv3 ([RFC3931]), and GRE ([RFC2784], = [RFC2890],
   [RFC4023]).


CMP: More comments below, but I am a bit = confused about the need to include MPLS-in-GRE, and the lack of IP-in-IP = (Tunnel Type 7) for example.
MPLS-in-GRE is = included in section 3.2 because there is already a tunnel type codepoint = allocated for it, and if that tunnel type is used, an encapsulation = sub-TLV is needed in order to signal the GRE key.

One can argue that there is no need for the MPLS-in-GRE = tunnel type, since everything you can do with it could be done instead = with the GRE tunnel type.  But unless and until we decide to = deprecate the MPLS-in-GRE tunnel type, it needs to be included. =    In theory, I would love to see the MPLS-in-GRE tunnel = type deprecated, but I worry that that might introduce a backwards = compatibility problem.    This is certainly something = that can be discussed by the WG.


I = agree =E2=80=94 and would welcome that discussion as well.

IP-in-IP is not mentioned in section 3.2 because, although = there is a tunnel type codepoint allocated for it, no one has ever = defined an encapsulation sub-TLV for it.  Also, if it is necessary = to signal values for the fields of the outer iP header, it might make = more sense to use an "outer encapsulation sub-TLV" (section 3.3). =  Do you have an opinion about this?

You = are right, Section 3.2 is indeed about the sub-TLVs. I believe I was = reacting to IP-in-IP not being mentioned anywhere (other than briefly in = the IANA section).

Perhaps I was = expecting something like this, although I agree with you it=E2=80=99s a = no-op:

3.2.x. IP-in-IP

   This document does not defines = an encapsulation sub-TLV for IP-in-IP = tunnels.
   When the tunnel type is IP-in-IP, the = encapsulation sub-TLV MUST NOT be used.

Now, IP-in-IP and other tunnels (like for example = MPLS-over-UDP) present an interesting question (that you raise above): = In these, is the encapsulation IP and UDP, or is this a null = encapsulation with an outer encapsulation of IP and UDP?

To me, the pragmatic case is to use the Outer = encapsulation sub-TLV for IP fields in IP-in-IP, and for UDP fields in = MPLS-over-UDP. 

However, if the = Tunnel Type is IP-in-IP (7), then using an Outer-encapsulation sub-TLV = would imply IP-in-IP-in-IP. Is IP-in-IP a null tunnel type with outer = encapsulation and with protocol =3D 0x0800? No. It is an IP-in-IP tunnel = type. No protocol (since the tunnel encap constraints it to IP), and no = outer encap. It is not =E2=80=9Cfurther encapsulated inside UDP and/or = IP=E2=80=9D as the text in section 1.3

It would certainly help to explain this = explicitly.

It gets equally = interesting with MPLS-over-UDP, because =E2=80=9CUDP=E2=80=9D is not a = tunnel type specified just yet, which could be used with MPLS protocol = type sub-TLV. Or a more limiting and duplicative MPLS-in-UDP tunnel = type.  What tunnel type is used there? null encap? protocol type = sub-TLV?

One additional comment =E2=80= =94 I could not figure out the sorting order for the encapsulations in = subsections 3.2.x. I would consider sorting by tunnel type value in = ascending order, and starting each sub-section with a =E2=80=9CThis = encapsulation sub-TLV is used when the Tunnel Type is XYZ (numerical = value)"


CMP: A couple of editorial comments as well: = For GRE, I think you also need to cite RFC 7676 (GRE over IPv6)
Sure.

Thank = you.


CMP: Also, having this document Obsolete RFC 5512 effectively = also orphans a number of Tunnel types and sub-TLVs. For example, Tunnel = Types values 3-6 from RFC 5566 (IPsec Tunnel Encap) and IPsec Tunnel = Authenticator sub-TLV. I do not know if the answer is to also have that = incorporated (useful parts as you say) and obsoleted. Maybe not, maybe = it does make sense given it is a short doc, which would lead to a = complete self-contained set of Tunnel types.
I = think RFC 5566 will have to be obsoleted and replaced.  I've been = thinking about that, but I'm still not sure how much of 5566 should be = moved into the tunnel-encaps draft and how much should be in a separate = draft.  There are some non-obvious issues to consider.  For = example, 5566 really is  just intended to facilitate iPsec Security = Associations between BGP Next Hops, but with the tunnel encapsulation = attribute we could presumably set up Security Associations from ingress = to egress.

Indeed. Thank you =E2=80=94 the goal would be that = 5566 does not get completely out-of-sync.


3.2.4.  L2TPv3

I forgot to mention, the way in which the = encapsulation sub-TLV is defined, this specifies only encapsulation for = L2TPv3 directly over IP. This section, as well as all references to it, = should be =E2=80=9CL2TPv3 over IP=E2=80=9D (like the tunnel type is = named now) http://www.iana.org/assignments/bgp-parameters/bgp-parameters.x= html#tunnel-types

L2TPv3 can = run:
* over IP: https://tools.ietf.org/html/rfc3931#section-4.1.1.1 
* over UDP: https://tools.ietf.org/html/rfc3931#section-4.1.2.1 

And L2TPv3 over UDP has a slightly = different encap header, so using the outer encap sub-TLV is not the way = to define L2TPv3 over UDP. Consequently, I=E2=80=99d explicitly say = =E2=80=9CL2TPv3 over IP=E2=80=9D everywhere.

=E2=80=A6
      Cookie: an = optional, variable length (encoded in octets -- 0 to 8
=       octets) value used by L2TPv3 to = check the association of a

CMP: The cookie = can only take sizes 0, 4, or 8 octets, and not 0..8
Do you have a reference for that?  Section = 4.1 of RFC 3931 seems to say only that the field is variable length with = a maximum size of 64 bits.
Yes, RFC 3931, when defining the Assigned = Cookie: https://tools.ietf.org/html/rfc3931#page-50 as well = as the 4th paragraph of S8.2 of RFC 3931.


3.2.7.  MPLS-in-GRE

CMP: This seems to be an example and not a = separate encapsulation type. This is GRE Type, with MPLS as protocol = sub-TLV. I see that the section says:

=    While it is not really necessary to have both the GRE = and MPLS-in-GRE
   tunnel types, both are = included for reasons of backwards
=    compatibility.

CMP: I = will also note that having two different ways of doing the same thing = (Tunnel Type 2 and protocol 0x8847 vs. Tunnel Type 11) takes us away = from interop., and that there does not seem to be MPLS-in-GRE defined in = any RFC (so it seems like potentially a good time to rationalize instead = of perpetuate). My $0.02 only.
Tunnel type 11 = is used by draft-ietf-bess-evpn-overlay.

CMP: Should MPLS-over-GRE be an = example only? Or otherwise, how do we interop the two types of =E2=80=9C = MPLS-over-GRE=E2=80=9D?
Well, the two ways of = doing the same thing are explicitly defined to be equivalent, so I don't = think there is an interop issue, the issue is more of "can we get rid of = the MPLS-in-GRE type without causing a backwards compatibility = problem=E2=80=9D.

Sorry, what I meant was if an endpoint understands = one way, and the other endpoint the other way only. 

I do not disagree with what you write, but an = explicit statement would not hurt (and may help)

Should an example be = also added about MPLS-over-L3TPv3?
Surely no = one will ever propose MPLS-over-L2TPv3 again!

I = meant it in the sense of why a special case for MPLS-over-GRE as its own = type.


3.3.1.  IPv4 DS Field

CMP: = Why not also define this for IPv6?
There are = a lot of possible Outer Encapsulation sub-TLVs that could be created, I = only included a couple of examples that seemed like they might be = useful.  If you have some sub-TLVs to suggest for the case where = the outer encapsulation is IPv6, please suggest some text. =   (Some IPv6-specific text will probably make it easier to get = the draft past the IESG ;-))

Sorry = I was not clear =E2=80=94 this is what I meant:

Section 3.3.1 is defining a DS field based on RFC = 2474. RFC 2474 in turn defines the DS field for the IPv4 TOS and the = IPv6 TC octets. 

Therefore, why = would this sub-section be suddenly limited to IPv4, when 2474 applies to = both IPv4 and IPv6?

In other words, = why not: =E2=80=9C3.3.1.  IP DS Field=E2=80=9D?

[I did not mean let=E2=80=99s have some = IPv6-specific sub-TLVs]

I have been = thinking about the Flow Label advertisement for IPv6, but I=E2=80=99m = still thinking about it :-)

Lastly, = this reminds me of a very small nit: Sections 3.6 (and others?) refers = to the MPLS ToS field, when that=E2=80=99s been renamed to the TC = field https://tools.ietf.org/html/rfc5462.


3.3.2. =  UDP Destination Port

CMP: One = additional thought. Obsoleting RFC 5512 also removes the anchor from RFC = 5640 =E2=80=94 that is not a terrible deal in itself, but is there also = an opportunity to generalize the Load-Balancing approach thereby defined = to also include the new encapsulations=E2=80=99 LB, UDP-based (port as = the LB Field), etc?
I wasn't aware of RFC = 5640.

I don't think there's anything in RFC = 5640 that requires the Encapsulation-SAFI.  So at a minimum, I = think we can get by with saying that the tunnel-encaps draft updates RFC = 5640, and that the LB Block sub-TLV can be included in the a tunnel TLV = of a tunnel encapsulation attribute that is attached to an update of any = AFI/SAFI.

Exactly.


If= you think it is worthwhile to generalize the load balancing approach of = RFC 5640, perhaps the best approach would be to do a 5640bis.

If = you don=E2=80=99t disagree, I think saying what you described two = paragraphs above would really help (and most likely be = sufficient).



I hope these are clear and useful =E2=80=94 = Thanks!

Looking forward to any = additional comments you might have!

Apologies for the delay in sending these out as well as with = this follow-up.

One additional small request =E2=80=94 in Section 12.5, could = we please reserve a couple of values for experiments?

=E2=80=9C
   IANA is requested to assign two = codepoints from the "BGP Tunnel
  =  Encapsulation Tunnel Types" registry for experimentation. = The 
   values 65534 and 65535 = are recommended for experimental use.
=E2=80=9C
=

Thanks!

=E2=80=94 = Carlos.

= --Apple-Mail=_2B05E73D-B176-45F5-B753-0C8C69FC1C2F-- --Apple-Mail=_0B18B767-0822-4372-8C6B-45EDC44516EF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJW07NgAAoJEIXgpQGOZny9hsYP/3iYBd2+CetnaIJ2gj2/HC1N GIxSMqoF0xig3hwK9b+baryMprkgXF1lTOqC7Dy8XbBfl7bVJ1cszTZrw7F8i4p4 LTHtqhvijKt8ekZdscmcHk3YbidhvaW9/q3rU6Oa7dGzuGfDEMlgfKRltpzN6NXk FRPdBz6jo2+A+ojnhMvdg3p7FFUb5XY/g1a+lf4rKB74geKUR5P6ARbhARI2ffAi LKUYfWh/cWXqUpGN9dHaGZEtO9+tnMmrEQbjkQi73/atfcJQ9mOEvkp+4XF2XKP/ QMmImq2/ZYmVL0AvnBR6bNX8IbRZREnBrpOaQ/YhoncmKWAkGqQy1rrHiFCoZpoY Kdr4Xck/4ZQK2/xNhF2JyTYGS1NgHxDtEfQ4X6O9ScmoOWhVRCykAl7okSXhkS5P hlJFfu2yRnZ1tJK/iWpF35aRe1cliJ2wSRWMXwQLycsc4AFcsNUv9NsHZcSIbJu8 MlCrKLIqjBRNC1ufU2XJTWywtx/Ue7kopXfXU/GvJT3VzDVSbM99tzRxx9Exm7/n uIItTIQJyl568oi97w7W4d2d3ATgNTcsSzIa4Q5bfYNiV6lSa0QEYVoqwS8QXQ2Y /SM2+wX2v5f5dLx1wjN3aX9iPB1CJsUzXYhIZZbViXwVDBPjOHgQM/Z+oPxjfwiH m9J3NmkSw5cfCQqpl+Qd =tLwz -----END PGP SIGNATURE----- --Apple-Mail=_0B18B767-0822-4372-8C6B-45EDC44516EF-- From nobody Mon Feb 29 02:45:40 2016 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 53B3C1B2FDB for ; Mon, 29 Feb 2016 02:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0akYrJfNgYm for ; Mon, 29 Feb 2016 02:45:37 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBDB51B2FDA for ; Mon, 29 Feb 2016 02:45:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1551; q=dns/txt; s=iport; t=1456742737; x=1457952337; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=STz/Qv4pOi65hUi6fZZxlr9iRqmc3n2eyuit6NkidNM=; b=YHpk1sKiERnHi6kXvqzL9KqJOjETFPB1N4i4xtbO8bb8Cv6illaaSW77 5wWbDlZqMIAm//nZS55JmYKLdIIQAqA/uRU5FizpzLvmplzPqYJUJOW2M YFp620L/qJxM+x98+qP3LDFlsq1l7/AUyWFp86Zo7w/8z4SMwbOO2Zyqy c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAgAJINRW/4QNJK1egzpSbQa6YgENg?= =?us-ascii?q?WcjhXACgS44FAEBAQEBAQFkJ4RBAQEBAwE6PQcLAgEZAwECHxAyGwIIAgQTiBc?= =?us-ascii?q?IDr5BAQEBAQEBAQMBAQEBAQEBAQEXhhKBbIJOh2CBDwWNK4VKhBcBhViCb4Uag?= =?us-ascii?q?V5Lg3mIUo5JAR4BAUKCMIE0agGHRH4BAQE?= X-IronPort-AV: E=Sophos;i="5.22,520,1449532800"; d="scan'208";a="77849458" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Feb 2016 10:45:36 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u1TAjaSt014503 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 29 Feb 2016 10:45:36 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 29 Feb 2016 04:45:36 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1104.009; Mon, 29 Feb 2016 04:45:36 -0600 From: "Stefano Previdi (sprevidi)" To: idr wg Thread-Topic: New Version Notification for draft-previdi-idr-bgpls-te-metric-extensions-00.txt Thread-Index: AQHRctzcnn+lOm6m8kytxEu0DpdeZw== Date: Mon, 29 Feb 2016 10:45:35 +0000 Message-ID: <2E563E2C-6F86-434D-B952-3E03F6136671@cisco.com> References: <20160229103504.4611.47204.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.74.12] Content-Type: text/plain; charset="us-ascii" Content-ID: <840E906C646A0B49949CC7A8D469D9E5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Idr] Fwd: New Version Notification for draft-previdi-idr-bgpls-te-metric-extensions-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, 29 Feb 2016 10:45:39 -0000 Hi, this draft is about BGPLS extensions for RFC7471 and draft-ietf-isis-te-met= ric-extensions. Thanks. s. > Begin forwarded message: >=20 > From: > Subject: New Version Notification for draft-previdi-idr-bgpls-te-metric-e= xtensions-00.txt > Date: February 29, 2016 at 11:35:04 AM GMT+1 > To: Clarence Filsfils , Les Ginsberg , Stefano Previdi >=20 >=20 > A new version of I-D, draft-previdi-idr-bgpls-te-metric-extensions-00.txt > has been successfully submitted by Stefano Previdi and posted to the > IETF repository. >=20 > Name: draft-previdi-idr-bgpls-te-metric-extensions > Revision: 00 > Title: BGP-LS Traffic Engineering (TE) Metric Extensions > Document date: 2016-02-29 > Group: Individual Submission > Pages: 9 > URL: https://www.ietf.org/internet-drafts/draft-previdi-idr-bg= pls-te-metric-extensions-00.txt > Status: https://datatracker.ietf.org/doc/draft-previdi-idr-bgpls-= te-metric-extensions/ > Htmlized: https://tools.ietf.org/html/draft-previdi-idr-bgpls-te-me= tric-extensions-00 >=20 >=20 > Abstract: > This document defines new BGP-LS TLVs in order to carry the IGP > Traffic Engineering Extensions defined in IS-IS and OSPF protocols. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Mon Feb 29 04:27:14 2016 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 C4A091B315D for ; Mon, 29 Feb 2016 04:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.657 X-Spam-Level: X-Spam-Status: No, score=-90.657 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BAYES_999=0.2, DOS_OUTLOOK_TO_MX=2.845, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 t9qXxSvrAzfz for ; Mon, 29 Feb 2016 04:27:12 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 4EA231B315B for ; Mon, 29 Feb 2016 04:27:12 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: Date: Mon, 29 Feb 2016 07:26:55 -0500 Message-ID: <06d501d172ec$7a99c080$6fcd4180$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06D6_01D172C2.91C3B880" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdFy7F7ye6rXfDp7TnaBWg6HLDzLdA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] Meeting on 2/29/2016 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, 29 Feb 2016 12:27:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06D6_01D172C2.91C3B880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all: The meeting on 2/29/2016 for IDR is cancelled. Sue ------=_NextPart_000_06D6_01D172C2.91C3B880 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all: =

 

The meeting on 2/29/2016 for IDR is cancelled. =  

 

Sue

------=_NextPart_000_06D6_01D172C2.91C3B880-- From nobody Mon Feb 29 07:50:40 2016 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 5FD271B34C3 for ; Mon, 29 Feb 2016 07:50:37 -0800 (PST) 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 9kHyPqZhTkYz for ; Mon, 29 Feb 2016 07:50:35 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 81BBC1B34C1 for ; Mon, 29 Feb 2016 07:50:35 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id l127so190267490iof.3 for ; Mon, 29 Feb 2016 07:50:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=xS6cGh4wSUNm0OHLswxaPIfhqfreS56uWsELzUC8btI=; b=rE00ijXD9LbyBLTYmzbUNp9feyTKGnMiBv6CJEm7ucU1O3ksjHGF4u+BQhJ+rjvLY9 mZu+4JtvpiIGCxoJdn8y4lT/dzMdjOOlzhADLgvqYgGlhkh/csoX9wWslt5AjWr4CIg0 hmrl0VkZPAwUmIgMjdFInxy8LoD4GZASTLyUMV2RS1xM6vZbFTXFTUTxHL8EyK5OIBRV fdtkSEiuqiv9OY7oRq75oNrJ5BzbOR+JTVAcW/j/jFN+vwxaJpYMEguqF1qZ1pn6XjEd qpek3HbgQW/dNpSxeMxh0syaFHHV4/SuIfVPQ4DS/XZdCD/TQyexXDTUE2kcU8muF4UJ iW6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=xS6cGh4wSUNm0OHLswxaPIfhqfreS56uWsELzUC8btI=; b=m0YzZzz+q6JLYdE+IsJauO5WGgX4sDYsGH00E1Pv+NqcLNFV2PygCp6O3wCuvwdv5A rl+MS2BiQSth3/zEHQUStXJqV2ZwearLyI2cZ9yGHBeNxdUkKcBFQtlfzzsCfCkd/xb4 fYBIr1kMJrVrrYlghBl4xIStGnac+vvGmPX20kDz4W3yUL0tExaU7wvXJdL+0CbUIele 3ajeD301b2YvTHeiucyqkVioo9G1lyml9dYF0e658V3n2GSAuk75lRtNZathhLan9k5C eZgIDO+P9ayQd/nCLbQCvuI2eXbMPeQR4sHW85auCVdune+e3VRLcX8xSmP7MqOVN263 CN7Q== X-Gm-Message-State: AG10YOSx8xsiPdcOrfCSggygPmVetvz59aA9qu84nzkbN85zloQPfi4POvT/1czJMU4U6nnAW+sRPNiO9Bw5pg== MIME-Version: 1.0 X-Received: by 10.107.165.17 with SMTP id o17mr23488846ioe.42.1456761034830; Mon, 29 Feb 2016 07:50:34 -0800 (PST) Received: by 10.50.36.41 with HTTP; Mon, 29 Feb 2016 07:50:34 -0800 (PST) In-Reply-To: <2E563E2C-6F86-434D-B952-3E03F6136671@cisco.com> References: <20160229103504.4611.47204.idtracker@ietfa.amsl.com> <2E563E2C-6F86-434D-B952-3E03F6136671@cisco.com> Date: Mon, 29 Feb 2016 21:20:34 +0530 Message-ID: From: Dhruv Dhody To: "Stefano Previdi (sprevidi)" Content-Type: multipart/alternative; boundary=001a1141fb1200fe4a052cea9c30 Archived-At: Cc: idr wg , "dhruv.dhody@huawei.com" Subject: Re: [Idr] Fwd: New Version Notification for draft-previdi-idr-bgpls-te-metric-extensions-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, 29 Feb 2016 15:50:37 -0000 --001a1141fb1200fe4a052cea9c30 Content-Type: text/plain; charset=UTF-8 Hi Stefano, What hapens to existing WG draft [ https://tools.ietf.org/html/draft-ietf-idr-te-pm-bgp-02] which you are also a co-author? Dhruv On Mon, Feb 29, 2016 at 4:15 PM, Stefano Previdi (sprevidi) < sprevidi@cisco.com> wrote: > Hi, > > this draft is about BGPLS extensions for RFC7471 and > draft-ietf-isis-te-metric-extensions. > > Thanks. > > s. > > > > Begin forwarded message: > > > > From: > > Subject: New Version Notification for > draft-previdi-idr-bgpls-te-metric-extensions-00.txt > > Date: February 29, 2016 at 11:35:04 AM GMT+1 > > To: Clarence Filsfils , Les Ginsberg < > ginsberg@cisco.com>, Stefano Previdi > > > > > > A new version of I-D, draft-previdi-idr-bgpls-te-metric-extensions-00.txt > > has been successfully submitted by Stefano Previdi and posted to the > > IETF repository. > > > > Name: draft-previdi-idr-bgpls-te-metric-extensions > > Revision: 00 > > Title: BGP-LS Traffic Engineering (TE) Metric Extensions > > Document date: 2016-02-29 > > Group: Individual Submission > > Pages: 9 > > URL: > https://www.ietf.org/internet-drafts/draft-previdi-idr-bgpls-te-metric-extensions-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-previdi-idr-bgpls-te-metric-extensions/ > > Htmlized: > https://tools.ietf.org/html/draft-previdi-idr-bgpls-te-metric-extensions-00 > > > > > > Abstract: > > This document defines new BGP-LS TLVs in order to carry the IGP > > Traffic Engineering Extensions defined in IS-IS and OSPF protocols. > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a1141fb1200fe4a052cea9c30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 29, 2016 at 4:1= 5 PM, Stefano Previdi (sprevidi) <sprevidi@cisco.com> wrote= :
Hi,

this draft is about BGPLS extensions for RFC7471 and draft-ietf-isis-te-met= ric-extensions.

Thanks.

s.


> Begin forwarded message:
>
> From: <internet-drafts@= ietf.org>
> Subject: New Version Notification for draft-previdi-idr-bgpls-te-metri= c-extensions-00.txt
> Date: February 29, 2016 at 11:35:04 AM GMT+1
> To: Clarence Filsfils <cfilsf= il@cisco.com>, Les Ginsberg <ginsberg@cisco.com>, Stefano Previdi <sprevidi@cisco.com>
>
>
> A new version of I-D, draft-previdi-idr-bgpls-te-metric-extensions-00.= txt
> has been successfully submitted by Stefano Previdi and posted to the > IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-previdi-idr-bgpls-te-metr= ic-extensions
> Revision:=C2=A0 =C2=A0 =C2=A000
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BGP-LS T= raffic Engineering (TE) Metric Extensions
> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2016-02-29
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu= al Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts= /draft-previdi-idr-bgpls-te-metric-extensions-00.txt
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-previdi-idr-= bgpls-te-metric-extensions/
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-previdi-idr-bgpls-te-metr= ic-extensions-00
>
>
> Abstract:
>=C2=A0 =C2=A0This document defines new BGP-LS TLVs in order to carry th= e IGP
>=C2=A0 =C2=A0Traffic Engineering Extensions defined in IS-IS and OSPF p= rotocols.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat
>

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

--001a1141fb1200fe4a052cea9c30-- From nobody Mon Feb 29 07:56:15 2016 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 B04681B342D for ; Mon, 29 Feb 2016 07:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTgXIRFnwKNy for ; Mon, 29 Feb 2016 07:56:13 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB4FF1A028A for ; Mon, 29 Feb 2016 07:56:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3198; q=dns/txt; s=iport; t=1456761372; x=1457970972; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ab01azVECynkmwvaslPOpESbp5xoseW3h8TPyZppG3I=; b=VREHFSDd8Wvj+AEcPS0++ha5VImx4IoEW5gn2YVrU6P2bUN04mjRcWQ3 Eaq6FdA+zNsUJA/1BDTYIboEiWQ2Xa5LAkS51lLOG2ozkFMfPOKXxblhh eTGguWMCm1PWb0itnQVKo9S9OaCZ+cAup/052O95ZiH8BKWi3mckjBmNJ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AQDfaNRW/51dJa1egzpSbQa6ZQENg?= =?us-ascii?q?WcXDIVwAhyBGDgUAQEBAQEBAWQnhEEBAQEDAQEBASAROgYDAgULAgEIEQMBAgE?= =?us-ascii?q?CAiYCAgIfBgsVCAgCBA4FiAoDCggOsE6KAg2ELQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARV7hReBbIJOgjqBYRiDAiuBDwWHU4VYgTGIMAGFWIJvgyaBdIFeS4N5iFK?= =?us-ascii?q?HBodDAR4BAUKCMIE0agGHRH4BAQE?= X-IronPort-AV: E=Sophos;i="5.22,521,1449532800"; d="scan'208";a="80810523" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Feb 2016 15:56:12 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u1TFuCGk028261 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Feb 2016 15:56:12 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 29 Feb 2016 09:56:11 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1104.009; Mon, 29 Feb 2016 09:56:10 -0600 From: "Stefano Previdi (sprevidi)" To: Dhruv Dhody Thread-Topic: [Idr] New Version Notification for draft-previdi-idr-bgpls-te-metric-extensions-00.txt Thread-Index: AQHRcwm1dh7EeC2hQE+PGyi6pNWIHA== Date: Mon, 29 Feb 2016 15:56:10 +0000 Message-ID: <43F9DF2C-9EB6-425B-B3EC-4D944F87E4D7@cisco.com> References: <20160229103504.4611.47204.idtracker@ietfa.amsl.com> <2E563E2C-6F86-434D-B952-3E03F6136671@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.74.12] Content-Type: text/plain; charset="utf-8" Content-ID: <03A6C5CD474EC148A14BAB96E7D2E8F9@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: idr wg , "dhruv.dhody@huawei.com" Subject: Re: [Idr] New Version Notification for draft-previdi-idr-bgpls-te-metric-extensions-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, 29 Feb 2016 15:56:14 -0000 SGkgRGhydXYsDQoNCnNvcnJ5LiBJIGRpZG7igJl0IGZpbmQgdGhlIHJlZmVyZW5jZSB0byB0aGF0 IGRyYWZ0IGFuZCBpdCBoYXMgZXhwaXJlZCBhIGxvbmcgd2hpbGUgYWdvLg0KDQpGaW5lIGJ5IG1l IHRvIHJlLWFjdGl2YXRlIGl0IGFuZCBtZXJnZSB0aGUgdHdvIChhdCB0aGlzIHN0YWdlIGl0IHdv dWxkIG1lYW4gbWVyZ2UgdGhlIGF1dGhvcuKAmXMgbGlzdCkuDQoNCnMuDQoNCg0KPiBPbiBGZWIg MjksIDIwMTYsIGF0IDQ6NTAgUE0sIERocnV2IERob2R5IDxkaHJ1di5pZXRmQGdtYWlsLmNvbT4g d3JvdGU6DQo+IA0KPiBIaSBTdGVmYW5vLCANCj4gDQo+IFdoYXQgaGFwZW5zIHRvIGV4aXN0aW5n IFdHIGRyYWZ0IFtodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pZHItdGUt cG0tYmdwLTAyXSB3aGljaCB5b3UgYXJlIGFsc28gYSBjby1hdXRob3I/IA0KPiANCj4gRGhydXYg DQo+IA0KPiBPbiBNb24sIEZlYiAyOSwgMjAxNiBhdCA0OjE1IFBNLCBTdGVmYW5vIFByZXZpZGkg KHNwcmV2aWRpKSA8c3ByZXZpZGlAY2lzY28uY29tPiB3cm90ZToNCj4gSGksDQo+IA0KPiB0aGlz IGRyYWZ0IGlzIGFib3V0IEJHUExTIGV4dGVuc2lvbnMgZm9yIFJGQzc0NzEgYW5kIGRyYWZ0LWll dGYtaXNpcy10ZS1tZXRyaWMtZXh0ZW5zaW9ucy4NCj4gDQo+IFRoYW5rcy4NCj4gDQo+IHMuDQo+ IA0KPiANCj4gPiBCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCj4gPg0KPiA+IEZyb206IDxpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1wcmV2aWRpLWlkci1iZ3Bscy10ZS1tZXRyaWMtZXh0ZW5zaW9ucy0wMC50 eHQNCj4gPiBEYXRlOiBGZWJydWFyeSAyOSwgMjAxNiBhdCAxMTozNTowNCBBTSBHTVQrMQ0KPiA+ IFRvOiBDbGFyZW5jZSBGaWxzZmlscyA8Y2ZpbHNmaWxAY2lzY28uY29tPiwgTGVzIEdpbnNiZXJn IDxnaW5zYmVyZ0BjaXNjby5jb20+LCBTdGVmYW5vIFByZXZpZGkgPHNwcmV2aWRpQGNpc2NvLmNv bT4NCj4gPg0KPiA+DQo+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXByZXZpZGktaWRy LWJncGxzLXRlLW1ldHJpYy1leHRlbnNpb25zLTAwLnR4dA0KPiA+IGhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgU3RlZmFubyBQcmV2aWRpIGFuZCBwb3N0ZWQgdG8gdGhlDQo+ID4g SUVURiByZXBvc2l0b3J5Lg0KPiA+DQo+ID4gTmFtZTogICAgICAgICBkcmFmdC1wcmV2aWRpLWlk ci1iZ3Bscy10ZS1tZXRyaWMtZXh0ZW5zaW9ucw0KPiA+IFJldmlzaW9uOiAgICAgMDANCj4gPiBU aXRsZTogICAgICAgICAgICAgICAgQkdQLUxTIFRyYWZmaWMgRW5naW5lZXJpbmcgKFRFKSBNZXRy aWMgRXh0ZW5zaW9ucw0KPiA+IERvY3VtZW50IGRhdGU6ICAgICAgICAyMDE2LTAyLTI5DQo+ID4g R3JvdXA6ICAgICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiA+IFBhZ2VzOiAg ICAgICAgICAgICAgICA5DQo+ID4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1wcmV2aWRpLWlkci1iZ3Bscy10ZS1tZXRyaWMtZXh0ZW5z aW9ucy0wMC50eHQNCj4gPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtcHJldmlkaS1pZHItYmdwbHMtdGUtbWV0cmljLWV4dGVuc2lvbnMvDQo+ ID4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wcmV2 aWRpLWlkci1iZ3Bscy10ZS1tZXRyaWMtZXh0ZW5zaW9ucy0wMA0KPiA+DQo+ID4NCj4gPiBBYnN0 cmFjdDoNCj4gPiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBuZXcgQkdQLUxTIFRMVnMgaW4gb3Jk ZXIgdG8gY2FycnkgdGhlIElHUA0KPiA+ICAgVHJhZmZpYyBFbmdpbmVlcmluZyBFeHRlbnNpb25z IGRlZmluZWQgaW4gSVMtSVMgYW5kIE9TUEYgcHJvdG9jb2xzLg0KPiA+DQo+ID4NCj4gPg0KPiA+ DQo+ID4NCj4gPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+ID4gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gPg0KPiA+ IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ID4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IElkciBtYWlsaW5nIGxpc3QNCj4gSWRyQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo+IA0KDQo=