[Idr] May a single UPDATE message carry multiple different AFI/SAFI combinations?

Deniz Bahadir <deniz.bahadir@benocs.com> Fri, 14 February 2020 13:47 UTC

Return-Path: <deniz.bahadir@benocs.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 09F85120041 for <idr@ietfa.amsl.com>; Fri, 14 Feb 2020 05:47:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9mmuBDrE4PGE for <idr@ietfa.amsl.com>; Fri, 14 Feb 2020 05:47:38 -0800 (PST)
Received: from mail.benocs.com (mx-01.benocs.com []) (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 <idr@ietf.org>; Fri, 14 Feb 2020 05:47:37 -0800 (PST)
Received: from localhost (localhost []) 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 ([]) by localhost (mail.benocs.com []) (amavisd-new, port 10024) with ESMTP id szfWLsJuY50C; Fri, 14 Feb 2020 14:40:58 +0100 (CET)
Received: from [] (ip-95-223-72-134.hsi16.unitymediagroup.de []) by mail.benocs.com (Postfix) with ESMTPSA id C96E864E6A2 for <idr@ietf.org>; Fri, 14 Feb 2020 14:40:58 +0100 (CET)
Reply-To: deniz.bahadir@benocs.com
From: Deniz Bahadir <deniz.bahadir@benocs.com>
Organization: BENOCS GmbH
To: idr@ietf.org
Message-ID: <84569374-e908-2a3d-07f9-8b4560364cf0@benocs.com>
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
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Hg56Wug4F8hdelbuNhIDHkql7Ws>
Subject: [Idr] May a single UPDATE message carry multiple different AFI/SAFI combinations?
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: 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 

However, it leaves me wondering if
   a) a single UPDATE message may carry an MP_REACH_NLRI as well as an 
   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

Dipl.-Inform. Deniz Bahadir
Reuchlinstr. 10 D
10553 Berlin
Phone: +49 - 30 / 577 0004-22
Email: deniz.bahadir@benocs.com

Board of Management: Stephan Schröder, Dr.-Ing. Ingmar Poese
Commercial Register: Amtsgericht Bonn HRB 19378