Subject: Re: [Idr] partial bit for ext. communities? -> update

From: "Thomas M. Knoll" <[email-masked]>
Date: Tue, 7 Apr 2009 18:44:29 +0200 (MEST)

One suggested solution to overcome the missing partial marking for 
single extended communities within a bunch of ext. communities was to send 
each ext. community separate in extended community attributes in order to 
use the partial bit of the attribute for the marking.
This procedure would either result in an UPDATE message containing just 
one of the bunch of ext. communities in each message, which in turn would lead 
to overriding the first with the second in the following UPDATE message.
Hence, "one per UPDATE" is no solution.

Secondly, the single ext. community per ext. com. attribute would lead to 
several instances of ext. com. attributes for the bunch of ext. 
communities within a single UPDATE message. This sounds sensible in the 
first run and avoids the override.
However, such behaviour leads to a BGP session tear down due to the 
"Malformed Attribute List" notification.

This is RFC conform behaviour since RFC 4271 states in 6.3:
"If any attribute appears more than once in the UPDATE message, then
    the Error Subcode MUST be set to Malformed Attribute List."

(I assume, that "any attribute appears more than once" relates to 
identical type numbers rather than fully binary identical attributes.)

Hence, multiple ext. communities MUST be sent bundled within one extended 
community attribute.

If I am not mistaken, this inevitably leads to the situation, where those 
transitive attributes are always relayed as beeing completely processed 
although the contained communities might or might not have been 
processed/understood.
A selective partial marking outside of ext. communities is not available 
and adding a fixed partial bit inside the ext. communities is arguably 
unattractive.

Please let me know, if I have missed or misunderstood a point here.

Thomas.

On Wed, 25 Mar 2009, Thomas M. Knoll wrote:

> Folks,
>
> within my presentation yesterday, I mentioned my observation about "unknown" 
> extended communities, which are relayed in BGP nodes without being marked as 
> partially processed.
> see slide 13 in
> http://www3.ietf.org/proceedings/09mar/slides/idr-5.pdf
>
> I was sending 4 of my new ext. communities (of regular type), which got 
> bundled into an extended community attribute and transferred to an commercial 
> router. This in turn relayed the attribute with the partial bit being 
> cleared.
>
> This router behaviour is arguably OK, since it did understand the extended 
> community attribute of type 16 and obviously did not care about the contained 
> bunch of not yet known ext. communities (of regular type 0x04).
>
> By means of this email, I would like to hear your opinion, whether you are 
> contended with such behaviour OR whether a partial bit in each extended 
> community would make the processing status of individual ext. communities 
> clearer.
>
> As far as I am aware of, there are no other extended communities of regular 
> type around (besides my own ones - 0x04, 0x44, 0x40), which would give the 
> chance to have a flags field next to the ext. community type, which could 
> host the proposed ext. community specific partial bit.
>
> Thomas.
>