Re: [Idr] WG Last Call on Extened Message Support

<bruno.decraene@orange.com> Tue, 12 March 2019 14:00 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 420E9130DCB for <idr@ietfa.amsl.com>; Tue, 12 Mar 2019 07:00:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 E8MF996B9PPI for <idr@ietfa.amsl.com>; Tue, 12 Mar 2019 07:00:04 -0700 (PDT)
Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC60126C87 for <idr@ietf.org>; Tue, 12 Mar 2019 07:00:03 -0700 (PDT)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 44Jc6n562nz10C8; Tue, 12 Mar 2019 15:00:01 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 44Jc6n3yx4zDq7h; Tue, 12 Mar 2019 15:00:01 +0100 (CET)
Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBM7D.corporate.adroot.infra.ftgroup ([fe80::bcfe:4850:e646:f223%21]) with mapi id 14.03.0439.000; Tue, 12 Mar 2019 15:00:01 +0100
From: bruno.decraene@orange.com
To: Randy Bush <randy@psg.com>
CC: Susan Hares <shares@ndzh.com>, Interminable Discussion Room <idr@ietf.org>
Thread-Topic: [Idr] WG Last Call on Extened Message Support
Thread-Index: AQHU14aj+2OiJ9BGQ0OMBTgzzooKKqYIB8lQ
Date: Tue, 12 Mar 2019 14:00:00 +0000
Message-ID: <31302_1552399201_5C87BB61_31302_314_2_53C29892C857584299CBF5D05346208A48A14AD8@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <024a01d4b7d8$f7925b90$e6b712b0$@olddog.co.uk> <4052_1548770128_5C505B50_4052_60_1_53C29892C857584299CBF5D05346208A489AEA6C@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <01a201d4c3ce$b6e6df10$24b49d30$@ndzh.com> <17281_1550132953_5C6526D9_17281_161_1_53C29892C857584299CBF5D05346208A489D3D92@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <00c901d4c489$8f311830$ad934890$@ndzh.com> <31634_1550226311_5C669387_31634_352_1_53C29892C857584299CBF5D05346208A489D6640@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <021401d4c9f9$8629c0f0$927d42d0$@ndzh.com> <5261_1550853971_5C702753_5261_459_1_53C29892C857584299CBF5D05346208A489E3592@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <m2r2befmzq.wl-randy@psg.com>
In-Reply-To: <m2r2befmzq.wl-randy@psg.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/EkNiCBUiWZcTQBuQx76BgoCUwtE>
Subject: Re: [Idr] WG Last Call on Extened Message Support
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 12 Mar 2019 14:00:10 -0000

Randy,

Thank you for the update.
-29 looks go to me but I still have the following comments:

§4

"treat as withdraw' (see [RFC7606]) a BGP attribue/NLRI pair which is too large to be sent to a peer which does not support BGP Extended Messages.

It's not clear to me whether the specification means sending the withdraw on all BGP sessions or only on the BGP sessions which do not support BGP Extended Message.
I can live with both choices but have a preference for the latter. I'd like the behavior be clarified in the specification.
In my understanding:
- For this draft, sending the withdraw only on the sessions not supporting BGP Extended Message would be enough, and would avoid disruption if someone enable a new BGP session not supporting BGP Extended Message
- RFC7606 is dealing with BGP update being received, hence does a withdrawn on all BGP sessions (including in the Loc-RIB of the speaker)

Hence there is a possible mismatch that people could try to interpret resulting in different behaviors.

-----
§6
OLD:
 For all messages except the OPEN
   message, if the receiver has advertised the capability to receive
   Extended Messages, this document raises that limit to 65535.

NEW:
 For all messages except the OPEN
   message, if the receiver has sent and advertised the BGP Extended Message Capability, this document raises that limit to 65535.
---
§3
OLD: A BGP speaker
   MAY send Extended Messages to its peer only if it has fully exchanged
   the Extended Message Capability with that peer.
   
   
I think me mean   
NEW: A BGP speaker MUST NOT send Extended Messages to its peer if it has not fully exchanged
   the Extended Message Capability with that peer.
---
1 feedback FYI,
In §5, you have changed
from OLD:
 A speaker
   MAY implement a more liberal policy and accept Extended Messages,
   even from a peer to which it has not advertised the capability, in
   the interest of preserving the BGP session if at all possible.

to NEW:
 A speaker
   SHOULD NOT implement a more liberal policy accepting BGP Extended
   Messages.
   
But section 8 still says:
   "Section 5 allowed a receiver to accept an Extended Message even
   though it had not advertised the capability.  This slippery slope
   could lead to sloppy implementations sending Extended Messages when
   the receiver is not prepared to deal with them, e.g. to peer groups.
   At best, this will result in errors; at worst, buffer overflows."
   
Strictly speaking, this is still correct, but significantly changing §5 without changing §8 might also be an oversight.   

Typo
:s/BGP attribue/BGP attribute

Thank you,
--Bruno

-----Original Message-----
From: Randy Bush [mailto:randy@psg.com] 
Sent: Sunday, March 10, 2019 10:17 PM
To: DECRAENE Bruno TGI/OLN
Cc: Susan Hares; Interminable Discussion Room
Subject: Re: [Idr] WG Last Call on Extened Message Support

i found your and susan's extended messages rather hard to follow and
therefore hard to apply to the once simple draft.  i have done what i
could.  simple comments, without quoting so much that it is impossible
to decode, appreciated.

randy

_________________________________________________________________________________________________________________________

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.