Well-known attributes must be recognized by all BGP implementations.
Some of these attributes are mandatory and must be included in every
UPDATE message. Others are discretionary and may or may not be sent
in a particular UPDATE message.
All well-known attributes must be passed along (after proper
updating, if necessary) to other BGP peers.
In addition to well-known attributes, each path may contain one or
more optional attributes. It is not required or expected that all
BGP implementations support all optional attributes. The handling of
an unrecognized optional attribute is determined by the setting of
the Transitive bit in the attribute flags octet. Paths with
unrecognized transitive optional attributes should be accepted. If a
path with unrecognized transitive optional attribute is accepted and
passed along to other BGP peers, then the unrecognized transitive
optional attribute of that path must be passed along with the path to
other BGP peers with the Partial bit in the Attribute Flags octet set
to 1. If a path with recognized transitive optional attribute is
accepted and passed along to other BGP peers and the Partial bit in
the Attribute Flags octet is set to 1 by some previous AS, it is not
set back to 0 by the current AS. Unrecognized non-transitive optional
attributes must be quietly ignored and not passed along to other BGP
peers.
New transitive optional attributes may be attached to the path by the
originator or by any other AS in the path. If they are not attached
by the originator, the Partial bit in the Attribute Flags octet is
set to 1. The rules for attaching new non-transitive optional
attributes will depend on the nature of the specific attribute. The
documentation of each new non-transitive optional attribute will be
expected to include such rules. (The description of the
MULTI_EXIT_DISC attribute gives an example.) All optional attributes
(both transitive and non-transitive) may be updated (if appropriate)
by ASs in the path.
The sender of an UPDATE message should order path attributes within
the UPDATE message in ascending order of attribute type. The
receiver of an UPDATE message must be prepared to handle path
attributes within the UPDATE message that are out of order.
The same attribute cannot appear more than once within the Path
Attributes field of a particular UPDATE message.
