Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)
<bruno.decraene@orange.com> Thu, 26 May 2016 09:18 UTC
Return-Path: <bruno.decraene@orange.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CE612D575 for <idr@ietfa.amsl.com>; Thu, 26 May 2016 02:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.344
X-Spam-Level:
X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 U5WThkNwmtui for <idr@ietfa.amsl.com>; Thu, 26 May 2016 02:18:50 -0700 (PDT)
Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4F112B026 for <idr@ietf.org>; Thu, 26 May 2016 02:18:49 -0700 (PDT)
Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id BA971205EE; Thu, 26 May 2016 11:18:48 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 729CB2006A; Thu, 26 May 2016 11:18:48 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0294.000; Thu, 26 May 2016 11:18:48 +0200
From: bruno.decraene@orange.com
To: "Keyur Patel (keyupate)" <keyupate@cisco.com>
Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)
Thread-Index: AQHRtp4l8Ct7z+m8+kGFNAEsHjbc55/K6Kxg
Date: Thu, 26 May 2016 09:18:47 +0000
Message-ID: <15012_1464254328_5746BF78_15012_699_1_53C29892C857584299CBF5D05346208A0F8D0469@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> <D36B14EC.40818%keyupate@cisco.com>
In-Reply-To: <D36B14EC.40818%keyupate@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F8D0469OPEXCLILM21corp_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/n3UQqkWf5RTsl2FBRKP2oqjzqok>
Cc: "idr@ietf.org" <idr@ietf.org>, Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 May 2016 09:18:53 -0000
Hi Keyur, Thanks for considering my comments and your prompt answer. Please see inlined #Bruno From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Wednesday, May 25, 2016 5:58 PM To: DECRAENE Bruno IMT/OLN; Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Hi Bruno, Many thanks for the review. Comments inlined #Keyur From: Bruno Decraene <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> Date: Wednesday, May 25, 2016 at 3:04 AM To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>, Keyur Patel <keyupate@cisco.com<mailto:keyupate@cisco.com>> Cc: "idr@ietf.org<mailto:idr@ietf.org>" <idr@ietf.org<mailto:idr@ietf.org>> Subject: RE: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Hi, 1) Support. 2) Question, for my own information: why does the capability mean that the BGP speaker is capable of _both_ receiving _and sending_ extend message? (vs capable of receiving (only)). IOTW, what is the motivation to advertise the capacity to send extended message? #Bruno: You may have missed the above question? It's linked to some of the below comments, so even though it's not a comment, it's useful to me / this thread. Thanks 3) Please find below some possible comments: "4. Operation" Suppose that I receive an extended BGP message (e.g. update) that I can't relay to some peers because they don't support such extension, while I "should" have relayed it. Is there an expected behavior? Should it be standardized? Can this create issues (e.g. inconsistent routing with an AS)? Should this be considered in the security considerations? (e.g. I deliberately send an extended message, and benefit from its/the NLRI not being propagated as expected. e.g. to influence routing policy) #Keyur: Clients would receive internal routes as long as a RR can announce prefixes using existing message length (of 4K). It would be using multiple messages limited to 4K length. #Bruno: Agreed. Alternatively, if the attribute size is such that the message length does get exceeded then the Prefix SHOULD not be announced and an error should be logged (existing case). #Bruno: That was indeed the issue I had in mind. I'm not seeing this point in the draft. Could this be added? Plus the consequences both within an AS and across ASes, in particular to raise this point to network operator (which may deploy this) and protocol designed (which may want to use it). This is partly similar to the "treat as withdraw" behavior described in RFC7606, so you may want to reuse existing text. cf "Operational Considerations" https://tools.ietf.org/html/rfc7606#section-6 In particular "we note that if an UPDATE message received on an Internal BGP (IBGP) session is subjected to this treatment, inconsistent routing within the affected Autonomous System may result. The consequences of inconsistent routing can include long-lived forwarding loops and black holes. > [...] < Even if inconsistent routing does not arise, the "treat-as-withdraw" behavior can cause either complete unreachability or suboptimal routing for the destinations whose routes are carried in the affected UPDATE message. > [...] "Because of these potential issues, a BGP speaker must provide debugging facilities to permit issues caused by a malformed attribute to be diagnosed. > An in term of warning to network operator and protocol designer, something along the following lines "Network operator needing to advertise within its AS a BGP route which size would require a BGP message larger than 4096 octets, SHOULD enabled this Extended Message capability on all BGP speaker needing to receive this routes. Failure to do so may result in inconsistent routing within its AS, as described above". "A protocol designer or network operator needing to advertise, outside of its AS, a BGP route which size would require a BGP message larger than 4096 octets should take into account that it has no guarantee that its route will be propagated as expected as a downstream BGP speaker might not be compliant or might not has enabled BGP extended messages and hence will not propagate the route. This is especially the case if one expect Internet wide propagation of its route, which seems highly improbable until a few years/decades". We could add the IPv6 example, to illustrate the time needed to deploy a new feature across the Internet, but I guess this would trigger some negative reactions. ---- #Bruno This document does not define the default behavior with regards to the advertisement of the capability. IMO, this point may impact the deployability of features using extended message and the security consideration. May be it should be enabled by default on IBGP session and disabled by default on EBGP sessions. -- "A BGP speaker may send extended messages to its peer only if it has received the Extended Message Capability from its peer." May be :s/received/sent and received --- #Keyur: A capability announcement indicates an ability to "receive and parse" extended messages. In that context "receive" is good enough? #Bruno: I agree with you in general, but this is not was this document states. "By advertising the BGP Extended Message Capability to a peer, a BGP speaker conveys that it is able to send, receive, and properly handle BGP Extended Messages. > " A BGP speaker that has the ability to use extended messages but has not advertised the BGP Extended Messages capability, presumably due to configuration, SHOULD NOT accept an extended message. A speaker MAY implement a more liberal policy and accept extended messages even from a peer that has not advertised the capability." I would a priori have assumed that both sentences be related. But in fact they are not since the first sentence only refers to the sending of the capability, while the second only refers to the reception of the capability. Shouldn't both sentences be extended to cover both the sending and the receiving? -- #Keyur: We wanted to be explicit in error handling section. :) Again, the capability meaning is to be able to "receive and parse". #Bruno: Again same comment. _This_ document has defined the capability to mean "send, receive and parse". "A speaker that treats an improper extended message as a fatal error, as described in the preceding paragraph, MUST do likewise. > I'm sorry but I don't understand this sentence. What does that mean to "treat an improper extended message as a fatal error"? e.g. If I receive an extended message with a syntax error requiring to send an NOTIFICATION (e.g. more than one MP_REACH_NLRI) is this considered an improper extended message with a fatal error? If so the text seems wrong as bgp speaker must not do "likewise" (seems to refer to "reset the session with a Bad Message Length NOTIFICATION") Also "as described in the preceding paragraph, MUST do likewise" seems not precise enough to me (at least as a non-native English speaker). Which exactly is this preceding paragraph describing this "treats an improper extended message as a fatal error" --- #Keyur: The text is meant for a BGP speaker that doesn't announce extended message capability AND doesn't support extended messages implementation (old style peer). Such a peer would consider a receipt of an extended message as a malformed message. #Bruno: ok, thanks for the clarification. I'm not sure to see the value of the quoted sentence. You are making a distinction/specific sub-case (a BGP which handled error as fatal error), to say that the behavior is the same. So it looks like removing the sentence would have the same effect. (no need for a specific case) 7. IANA Considerations "The IANA is requested to register a new BGP Capability Code to be named BGP Extended Message Capability > I'm not sure about the formulation since IANA has already registered this capability as TEMPORARY. "TBD BGP-Extended Message" At least I would expect that the document ask for the _same_ value (6) rather than TBD. #Keyur: Ack. Regards, Keyur Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, May 24, 2016 10:42 PM To: idr@ietf.org<mailto:idr@ietf.org> Cc: 'Keyur Patel (keyupate)'; 'David Ward' Subject: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) This begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages (5/24 to 6/7). The draft can be found at: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ In your comments please provide the following information: 1) Support/"no-support" of this draft being ready for publication, 2) You know of an implementation for this draft, please report the implementation to the IDR Wiki https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-bgp-extended-implementations 3) Do you have any concerns about extending the BGP messages. Sue Hares and John Scudder _________________________________________________________________________________________________________________________ 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. _________________________________________________________________________________________________________________________ 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.
- [Idr] draft-ietf-idr-bgp-extended-messages-12 WG … Susan Hares
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Job Snijders
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Acee Lindem (acee)
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Christopher Morrow
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… heasley
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Jeff Tantsura
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Randy Bush
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Van De Velde, Gunter (Nokia - BE)
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Randy Bush
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Gunter Van De Velde
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Randy Bush
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Van De Velde, Gunter (Nokia - BE)
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… bruno.decraene
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Randy Bush
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Van De Velde, Gunter (Nokia - BE)
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Robert Raszuk
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Acee Lindem (acee)
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Acee Lindem (acee)
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… bruno.decraene
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Robert Raszuk
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Robert Raszuk
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Acee Lindem (acee)
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Robert Raszuk
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Keyur Patel (keyupate)
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Keyur Patel (keyupate)
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Keyur Patel (keyupate)
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Robert Raszuk
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Keyur Patel (keyupate)
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Robert Raszuk
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Keyur Patel (keyupate)
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Keyur Patel (keyupate)
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Robert Raszuk
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Keyur Patel (keyupate)
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Sriram, Kotikalapudi (Fed)
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Sriram, Kotikalapudi (Fed)
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Robert Raszuk
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Ignas Bagdonas
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Russ White
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Zhuangshunwan
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… bruno.decraene
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Robert Raszuk
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Randy Bush
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Robert Raszuk
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Jeffrey Haas
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Susan Hares
- Re: [Idr] draft-ietf-idr-bgp-extended-messages-12… Susan Hares