Re: [Idr] WG Last Call on Extened Message Support
"Adrian Farrel" <adrian@olddog.co.uk> Tue, 29 January 2019 13:46 UTC
Return-Path: <adrian@olddog.co.uk>
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 9ACD71200D7 for <idr@ietfa.amsl.com>; Tue, 29 Jan 2019 05:46:05 -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 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 KPDT47FtYPXP for <idr@ietfa.amsl.com>; Tue, 29 Jan 2019 05:46:01 -0800 (PST)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 37FB2124408 for <idr@ietf.org>; Tue, 29 Jan 2019 05:46:01 -0800 (PST)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id x0TDjw6d028061; Tue, 29 Jan 2019 13:45:58 GMT
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6072E22040; Tue, 29 Jan 2019 13:45:58 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS id 4A1812203D; Tue, 29 Jan 2019 13:45:58 +0000 (GMT)
Received: from LAPTOPK7AS653V ([87.112.189.92]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x0TDju36027145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Jan 2019 13:45:57 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: bruno.decraene@orange.com, 'Susan Hares' <shares@ndzh.com>
Cc: idr@ietf.org
References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
In-Reply-To: <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
Date: Tue, 29 Jan 2019 13:45:58 -0000
Organization: Old Dog Consulting
Message-ID: <024a01d4b7d8$f7925b90$e6b712b0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_024B_01D4B7D8.F79568D0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJ3UJ5j1bTPsyO86K1JuAQ7q/LpfQIdyv9rpHAhFLA=
Content-Language: en-gb
X-Originating-IP: 87.112.189.92
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24396.007
X-TM-AS-Result: No--22.859-10.0-31-10
X-imss-scan-details: No--22.859-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24396.007
X-TMASE-Result: 10--22.858700-10.000000
X-TMASE-MatchedRID: Z/tjqhsgM6c7iuZ/mdYYtto4g/Zvpl9fFMEPs5fzSwvKwJG6rXlLlCr8 0cckpha37H2DvWppibOVUcz8XpiS9Oj86Ng8AayKDO+DX+rUwfa/35G8ZJR1gDBMulrsuwreNHL VIJgMRcq8NFvOvNqhNQs9VkfCh3uA9pLnYtQ99xLdeAKnvBMxfLAH9XNsgOEsqQSZBgEX4Igepw +z9Es2aswdQieqpnTaHcQQBuf4ZFtRpe71pI4bhViVnpu6eNDRwrjXAJniWtcm+OJfOTgVT88pY J542tkjQjr0vbZGNcsSEYfcJF0pRWEF8bGZ0cKChc+Jw4LMtcBBWFCS0LqYKgXYJoM72R8HXTPY ACRSxowvRbVu13x7nsNrWpY804TGh8Ytn75ClDNZps+y1VXzqWskpsLNM/2r7ICOc5aTsToxK06 rCzlCCNEbg9qbbdscEzEoOqAAVLOJDcnxSM8mRY1Oeo4wEgnhR05HQqBvtpcbwXX3Ig0oLKz/Hk nfmGOQuV6k5h94860YBkxPlIuYCePmXK6rwg5B/780mhEUzN5NqQ8f407TsdgHGYVebl3m3c3CR Ad2bOG/oFcrg/+LVnxTDivx6nwGuCESrx7wlnJ0TRq4bcxmH3TOpWZZiMb9goo9VklhlSzTYAo4 jA2DyD/dR69VedHqRW35EzqKbf7WfMC/MJjarK7jTxz2XLzXSdhRWWY5SwyKK3RHbODlwcBvU+t 6p8hAKRmW/QELuJ5ZF83jMVouh3daCg+TDtvVJ3SY4a1wRsL/3GSyK1ZTWTMWjhaiUHn+piIVsI k03Fr6sqlOEW2ZPcL6jhga4Ht7kdS3kPlaZyWbKItl61J/yZUdXE/WGn0FAOtc250L4nR6mbStZ ofccrmjfIGRDEdmsOzOncrmCoOFR9Hau8GO7qKzIEJ73VDeHseTTbN+yg3QCHrODdYLU5L+0EOZ fn8sJCE+VhzVrcY=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/nbYJJEvZjE91XmsMvGUqmd4xZr0>
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, 29 Jan 2019 13:46:06 -0000
The solution to: * BGP-LS needs extended message support * No one has implemented BGP extended message support would appear to be to have implementations of BGP-LS implement BGP extended message support. Then everyone would be happy. Adrian From: Idr <idr-bounces@ietf.org> On Behalf Of bruno.decraene@orange.com Sent: 29 January 2019 13:33 To: Susan Hares <shares@ndzh.com> Cc: idr@ietf.org Subject: Re: [Idr] WG Last Call on Extened Message Support Hi WG, Please find below some comments. As of today, I dont believe this specification is ready to be progressed to IESG/RFC, especially for a document updating RFC 4271 (core BGP spec). > The WG chairs intend to forward this draft to the IESG with the current level of implementation. https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementati ons says : 5a Does not send Extended Message capability Yes Yes Yes I may be misunderstanding the implementation report, but my reading of the above is that none of the reported implementations sends the capability hence no implementation supports draft-ietf-idr-bgp-extended-messages.. Here this document is updating RFC 4271, so it is not a minor extension for a niche use case. So I dont see the arguments for not requiring the IDRs usual two interoperable implementations. ---- § 1 As BGP is extended to support newer AFI/SAFIs and newer capabilities (e.g., [ <https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#ref-I-D .ietf-sidr-bgpsec-protocol> I-D.ietf-sidr-bgpsec-protocol]), there is a need to extend the maximum message size beyond 4096 octets. https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#section- 1 [ <https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#ref-I-D .ietf-sidr-bgpsec-protocol> I-D.ietf-sidr-bgpsec-protocol is now RFC 8205 (thanks for updating the reference). It has removed the normative/any reference to draft-ietf-idr-bgp-extended-messages. So presumably BGP Sec does not need draft-ietf-idr-bgp-extended-messages. Can we have an update on this? Can the introduction of draft-ietf-idr-bgp-extended-messages be updated to introduce on the real reasons/needs? ---- §4 §3 says A peer which does not advertise this capability MUST NOT send BGP Extended Messages, and BGP Extended Messages MUST NOT be sent to it. Fine. Text in §4 should probably be aligned with the above .e.g. OLD: A BGP speaker MAY send Extended Messages to its peer only if it has received the Extended Message Capability from that peer. NEW: A BGP speaker MAY send Extended Messages to its peer only if it has sent and received the Extended Message Capability to and from that peer. ---- Applications generating information which might be encapsulated within BGP messages MUST limit the size of their payload to take the maximum message size into account. I dont see what new behavior is been defined here. If there is none, I would suggest to remove this sentence ---- A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which can not be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. The issue is not specific to attributes bigger than 4096 octets, but to BGP message whose length is bigger than 4096, irrespective of the size of each attribute. Please elaborate on what you mean by an attribute which can not be decomposed to 4096 octets --- It is RECOMMENDED that BGP protocol developers and implementers are conservative in their application and use of Extended Messages. What does this mean exactly? That they dont use this extension? That they dont use this extension unless XX_TO BE SPECIFIED_XX? --- Future protocol specifications will need to describe how to handle peers which can only accommodate 4096 octet messages. Why is this limited to future specifications? A priori, using existing BGP mechanism (AFI/SAFI, attributes, * communities) one could exceed the size of 4096 octets. How does the BGP speaker supposed to behave in this case? This should be described in this specification. Note that this is not a case of error handling, as every BGP speaker is behaving as specified. ---- Depending on the above specification, a section describing the operational consequences in a network (such as the Internet, BGP Enabled ServiceS/VPN networks) is probably needed. Possible consequences could be BGP NLRI being removed in the middle of such network, or (extended) community (such as Route Targets) been removed. Both having significant consequences on the availability provided by the network. --- §4 OLD: The Extended Message Capability only applies to all messages except for the OPEN message. Probably NEW: The Extended Message Capability applies to all message types except for the OPEN message (type 1). ---- §8 This extension to BGP does not change BGP's underlying security issues » Before evaluating this, I think this document should first specified how a BGP messages bigger than 4096 octets is handled when it needs to be sent to a received not supporting this extension. Nits: OLD : to reduce compexity NEW : to reduce complexity Thanks, --Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, January 29, 2019 12:33 PM To: idr@ietf.org <mailto:idr@ietf.org> Subject: [Idr] WG Last Call on Extened Message Support This begins a 2 week WG LC on Extended Message Support for BGP (draft-ietf-idr-bgp-extended-messages-27). You can access the draft at: <https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ The authors should indicate whether they know of any IPR. Implementers are encouraged to update the implementation data at: <https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementat ions> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementati ons The draft provides a means for expanding the BGP message to 65535 octets for all messages except OPEN messages. BGP message space is running short for all of the potential attributes or additions proposed by BGP-LS features. The WG chairs intend to forward this draft to the IESG with the current level of implementation. As you comment on the draft, please consider if: a) the technology is mature, b) the additional space in a BGP message would be helpful for those deploying BGP-LS or SR, and c) if the specification is ready for publication. Sue Hares (WG Chair, Shepherd) ____________________________________________________________________________ _____________________________________________ 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] WG Last Call on Extened Message Support Susan Hares
- Re: [Idr] WG Last Call on Extened Message Support bruno.decraene
- Re: [Idr] WG Last Call on Extened Message Support Adrian Farrel
- Re: [Idr] WG Last Call on Extened Message Support bruno.decraene
- Re: [Idr] WG Last Call on Extened Message Support Susan Hares
- Re: [Idr] WG Last Call on Extened Message Support Susan Hares
- Re: [Idr] WG Last Call on Extened Message Support Susan Hares
- Re: [Idr] WG Last Call on Extened Message Support bruno.decraene
- Re: [Idr] WG Last Call on Extened Message Support bruno.decraene
- Re: [Idr] WG Last Call on Extened Message Support Randy Bush
- Re: [Idr] WG Last Call on Extened Message Support Susan Hares
- Re: [Idr] WG Last Call on Extened Message Support Susan Hares
- Re: [Idr] WG Last Call on Extened Message Support Borchert, Oliver (Fed)
- Re: [Idr] WG Last Call on Extened Message Support Borchert, Oliver (Fed)
- Re: [Idr] WG Last Call on Extened Message Support Susan Hares
- Re: [Idr] WG Last Call on Extened Message Support Dongjie (Jimmy)
- Re: [Idr] WG Last Call on Extened Message Support bruno.decraene
- Re: [Idr] WG Last Call on Extened Message Support Susan Hares
- Re: [Idr] WG Last Call on Extened Message Support Dongjie (Jimmy)
- Re: [Idr] WG Last Call on Extened Message Support Jakob Heitz (jheitz)
- Re: [Idr] WG Last Call on Extened Message Support Susan Hares
- Re: [Idr] WG Last Call on Extened Message Support Susan Hares
- Re: [Idr] WG Last Call on Extened Message Support Jakob Heitz (jheitz)
- Re: [Idr] WG Last Call on Extened Message Support Susan Hares
- Re: [Idr] WG Last Call on Extened Message Support Randy Bush
- Re: [Idr] WG Last Call on Extened Message Support Robert Varga
- Re: [Idr] WG Last Call on Extened Message Support Susan Hares
- Re: [Idr] WG Last Call on Extened Message Support bruno.decraene
- Re: [Idr] WG Last Call on Extened Message Support bruno.decraene
- Re: [Idr] WG Last Call on Extened Message Support Susan Hares
- Re: [Idr] WG Last Call on Extened Message Support Robert Raszuk
- Re: [Idr] WG Last Call on Extened Message Support Susan Hares
- Re: [Idr] WG Last Call on Extened Message Support bruno.decraene
- Re: [Idr] WG Last Call on Extened Message Support Jakob Heitz (jheitz)
- Re: [Idr] WG Last Call on Extened Message Support Susan Hares
- Re: [Idr] WG Last Call on Extened Message Support Susan Hares
- Re: [Idr] WG Last Call on Extened Message Support bruno.decraene
- Re: [Idr] WG Last Call on Extened Message Support Randy Bush
- Re: [Idr] WG Last Call on Extened Message Support Susan Hares
- Re: [Idr] WG Last Call on Extened Message Support Claudio Jeker
- Re: [Idr] WG Last Call on Extened Message Support bruno.decraene
- Re: [Idr] WG Last Call on Extened Message Support Claudio Jeker
- Re: [Idr] WG Last Call on Extened Message Support Susan Hares