bgp update...

as-path, origin and next hop are well known transitive... it has to be true, it says so right in the update packet...

bgp update...

the update tells you the shit... you can just read it and expect to know it... you have to be it...

the update message (type 2)

origin, code 1, well known transitive

as_path, code 2, well known transitive

next_hop, code 3, well known transitive

and nlri follows...

zoom in...

The mandatory category refers to an attribute that MUST be present in
   both IBGP and EBGP exchanges if NLRI are contained in the UPDATE
   message.  Attributes classified as optional for the purpose of the
   protocol extension mechanism may be purely discretionary,
   discretionary, required, or disallowed in certain contexts.

        attribute           EBGP                    IBGP
         ORIGIN             mandatory               mandatory
         AS_PATH            mandatory               mandatory
         NEXT_HOP           mandatory               mandatory
         MULTI_EXIT_DISC    discretionary           discretionary
         LOCAL_PREF         see Section 5.1.5       required
         ATOMIC_AGGREGATE   see Section 5.1.6 and 9.1.4
         AGGREGATOR         discretionary           discretionary

ORIGIN is a well-known mandatory attribute.  The ORIGIN attribute is
   generated by the speaker that originates the associated routing
   information.  Its value SHOULD NOT be changed by any other speaker.

AS_PATH is a well-known mandatory attribute.  This attribute
   identifies the autonomous systems through which routing information
   carried in this UPDATE message has passed.  The components of this
   list can be AS_SETs or AS_SEQUENCEs.

 The NEXT_HOP is a well-known mandatory attribute that defines the IP
   address of the router that SHOULD be used as the next hop to the
   destinations listed in the UPDATE message.

what doyle says 

Well-known attributes are either mandatory, meaning that they must be included in all BGP
Update messages, or they are discretionary , meaning that they may or may not be sent in a
specific Update message.
If an optional attribute is transitive , a BGP process should accept the path in which it is
included, even if it doesn’t support the attribute, and it should pass the path on to its peers.

If an optional attribute is nontransitive , a BGP process that does not recognize the attribute
can quietly ignore the Update in which it is included and not advertise the path to its other
peers.
 

ORIGIN is a well-known mandatory attribute that specifies the origin of the routing update.
When BGP has multiple routes, it uses the ORIGIN as one factor in determining the
preferred route.

AS_PATH is a well-known mandatory attribute that uses a sequence of AS numbers to
describe the inter-AS path, or route, to the destination specified by the NLRI. When a BGP
speaker originates a route—when it advertises NLRI about a destination within its own
AS—it adds its AS number to the AS_PATH. As subsequent BGP speakers advertise the
route to external peers, they prepend their own AS numbers to the AS_PATH

The NEXT_HOP Attribute
As the name implies, this well-known mandatory attribute describes the IP address of the
next-hop router on the path to the advertised destination. The IP address described by the
BGP NEXT_HOP attribute is not always the address of a neighboring router.  

jeff has prettier fonts and stuff... 

bgp notification...

to get a notification message, there needs to be an error... changing the neighbor remote-as will effect such an error...

look at the message types in rfc4271:

Type:

         This 1-octet unsigned integer indicates the type code of the
         message.  This document defines the following type codes:

                              1 - OPEN
                              2 - UPDATE
                              3 - NOTIFICATION
                              4 - KEEPALIVE

 open
   After a TCP connection is established, the first message sent by each
   side is an OPEN message.  If the OPEN message is acceptable, a
   KEEPALIVE message confirming the OPEN is sent back.

 UPDATE messages are used to transfer routing information between BGP
   peers. 

 An UPDATE message MAY simultaneously
   advertise a feasible route and withdraw multiple unfeasible routes
   from service.

 A NOTIFICATION message is sent when an error condition is detected.
   The BGP connection is closed immediately after it is sent.

Keepalive 

 BGP does not use any TCP-based, keep-alive mechanism to determine if
   peers are reachable.  Instead, KEEPALIVE messages are exchanged
   between peers often enough not to cause the Hold Timer to expire.