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.