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

From: Deniz Bahadir <[email-masked]>
Date: Fri, 14 Feb 2020 14:47:32 +0100

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: [email-masked]
www.benocs.com

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