[Idr] May a single UPDATE message carry multiple different AFI/SAFI combinations?
Deniz Bahadir <firstname.lastname@example.org> Fri, 14 February 2020 13:47 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F85120041 for <email@example.com>; Fri, 14 Feb 2020 05:47:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([18.104.22.168]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mmuBDrE4PGE for <firstname.lastname@example.org>; Fri, 14 Feb 2020 05:47:38 -0800 (PST)
Received: from mail.benocs.com (mx-01.benocs.com [22.214.171.124]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E5F9120074 for <email@example.com>; Fri, 14 Feb 2020 05:47:37 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.benocs.com (Postfix) with ESMTP id D7AB264E8DA; Fri, 14 Feb 2020 14:41:00 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at benocs.com
Received: from mail.benocs.com ([127.0.0.1]) by localhost (mail.benocs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szfWLsJuY50C; Fri, 14 Feb 2020 14:40:58 +0100 (CET)
Received: from [192.168.78.138] (ip-95-223-72-134.hsi16.unitymediagroup.de [126.96.36.199]) by mail.benocs.com (Postfix) with ESMTPSA id C96E864E6A2 for <firstname.lastname@example.org>; Fri, 14 Feb 2020 14:40:58 +0100 (CET)
From: Deniz Bahadir <email@example.com>
Organization: BENOCS GmbH
Date: Fri, 14 Feb 2020 14:47:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
Content-Type: text/plain; charset="utf-8"; format="flowed"
Subject: [Idr] May a single UPDATE message carry multiple different AFI/SAFI combinations?
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2020 13:47:42 -0000
Hi everyone, I have a question which is probably easy to answer for you experts but I am struggling to find the RFCs which completely answer it. The question reads: Can a single BGP UPDATE message carry NLRI with different AFI/SAFI combinations (and still be valid)? On the search for an answer I found some RFCs that partially answer it but not entirely and which made me come up with even more questions... RFC 7606 ("Revised Error Handling for BGP UPDATE Messages") states in section 3 g): ``` If the MP_REACH_NLRI attribute or the MP_UNREACH_NLRI [RFC4760] attribute appears more than once in the UPDATE message, then a NOTIFICATION message MUST be sent with the Error Subcode "Malformed Attribute List". [...] ``` This clearly states that multiple MP_REACH_NLRI in a single UPDATE message are not allowed and so only one explicit AFI/SAFI combination can be carried in an UPDATE message which advertises new routes. Similar, it states that multiple MP_UNREACH_NLRI are not allowed in a single UPDATE message and therefore only one explicit AFI/SAFI combination can be carried in an UPDATE message which are advertised as withdrawn. However, it leaves me wondering if a) a single UPDATE message may carry an MP_REACH_NLRI as well as an MP_UNREACH_NLRI and b) if these may then carry different AFI/SAFI combinations? Additionally, this section does not say anything about the traditional fields of an UPDATE message (which carry implicit AFI/SAFI combination of IPv4/unicast): May these carry (added or withdrawn) NLRI in the presence of MP_REACH_NLRI or MP_UNREACH_NLRI? And may the MP_REACH_NLRI (or MP_UNREACH_NLRI) then carry other AFI/SAFI than IPv4/Unicast? RFC 4760 ("Multiprotocol Extensions for BGP-4") says in section 3: ``` An UPDATE message that carries no NLRI, other than the one encoded in the MP_REACH_NLRI attribute, SHOULD NOT carry the NEXT_HOP attribute. If such a message contains the NEXT_HOP attribute, the BGP speaker that receives the message SHOULD ignore this attribute. ``` This seems to imply that a single UPDATE message _can_ carry an MP_REACH_NLRI for a specific AFI/SAFI combination as well as IPv4/unicast NLRI using the traditional UPDATE fields described in RFC 4271. Is this really the intention and therefore allowed? So, my original question pretty much unfolds into the following questions: - May in the presence of MP_REACH_NLRI (or MP_UNREACH_NLRI) the traditional fields of an UPDATE message carry NLRI (or withdrawn NLRI), too? - Does any RFC explicitly say whether that is allowed or not? - Or might this only be allowed if the MP_REACH_NLRI (or MP_UNREACH_NLRI) contains the same AFI/SAFI combination of IPv4/unicast? - What do the different existing implementations for BGP do? What do they accept in receiving UPDATE messages? - Is carrying both, added as well as withdrawn NLRI (either using the traditional fields or with MP_REACH_NLRI and MP_UNREACH_NLRI) in a single UPDATE message still allowed? - Does any implementation still do this? While writing this e-mail the questions became more and more. I hope that some of you can still help me answering these. Thanks in advance, Deniz Bahadir -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Reuchlinstr. 10 D 10553 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: firstname.lastname@example.org www.benocs.com Board of Management: Stephan Schröder, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378
- [Idr] May a single UPDATE message carry multiple … Deniz Bahadir