BGP Peer Auto-Configuration

Abstract

This document describes a layer 3 protocol (Service advertisement) to help bgp to advertise service availability and local configurations . This enable bgp speakers to discover bgp peers transport endpoints and peer's configuration within link. With Service advertisement, receivers could successfully bring up bgp protocol session without mundane configurations.¶

1. Introduction

This document describes a layer 3 protocol (Service advertisement)to help bgp to advertise service availability and local configurations . This enable bgp speakers to discover bgp peers transport endpoints and peer's configuration within link. With Service advertisement, receivers could successfully bring up bgp protocol session without mundane configurations.¶

2. Protocol overview

This is a simple protocol, periodically send and receive UDP multicast PDU that contains bgp transport information in the form of messages and TLVs. Receiver could use this information to bootstrap the 1hop bgp and/or loopback address bgp between directly connected bgp speakers. The advertised information gets expired if not refreshed before the lifetime.¶

This protocol does not provide any reliability of delivery and relay on UDP multicast and periodic send. The current version of this protocol assumes the link MTU is good enough to encode BGP transport information or underlying IP implementation able to do fragment and reassembly for link local multicast PDU. But this protocol flexible enough implements a future version of fragment TLV attachment to bypass the smaller link MTU for the system or environment prevent IP fragment.¶

Service Advertisement (SA) PDU has multiple types of messages. This document defines 2 types of messages. The primary/base messages are required for SA to operates and secondary type messages for BGP service advertisement.¶

3. PUD layers

The PDU contains a header followed by variable number of messages. Each message contains variable number of TLVs.¶

SA uses type length value format.¶

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |      Length                       |  Value    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Value ..
 +-+-+-+-+

Type: This 1-octet value to define how to interpret the value with in message. The same type value could be reused in different message.¶

Length: Specifies length in octets of the value field.¶

Value: Octet string that encodes information to be interpreted as specified by the Type field.¶

SA uses message to group set of TLVs¶

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|message Type |      Length                     | Reserved      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message ID                                                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs
+-----

message Type: This 1-octet value identifies type of message.¶

Message Length: Specifies the length in octets of the Message ID and TLVs.¶

Message ID :32-bit value used to identify this message. Used for logging purpose.¶

SA PDU¶

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Version   |      PDU Length               |     Reserved  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Identifier.                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Messages
 +-----

Version: This 1-octet unsigned integer indicates the protocol version. This version of the specification specifies Service Advertisement version 0.¶

Message Length: Length of the PDU.¶

PDU Length: This 2-octet unsigned integer specifies the length¶

Identifier: 4 octet field that uniquely identifies PDU sender. BGP id could be used for this purpose. This help to uniquely identify sender across the parallel links between same nodes.¶

4. Messages

The document defines following messages.¶

1. SA Base message¶
2. BGP service advertisement message¶

5. Protocol operation

A sender should periodically send PDU to refresh the advertised information before remaining life become zero.¶

A sender should send the PDU to refresh the before the advertised remaining lifetime expire. If bgp is only configured with only one transport address family(IPv4/v6) then sender shall only send corresponding data protocol PDU. If both addresses are configured, then it shall use both data protocol PDU. PDUs are send with source address as link primary address and destination is link local all-routers with TTL 255. if the authentication is enabled then add authentication TLV using the authentication procedure described in [TBD]. Populated other TLVs based on local preference and send the PDU in configured link. The sematic content (transport and session information) of the PDU should be same irrespective the data protocol.¶

Receiver reset refresh of the state whenever it accepts the PDU irrespective of the data protocol. Receiver shall add a route for the address in local address TLV with nexthop as source address of the PDU if PUD data protocol and local address is same address family. Otherwise if link address is available and link address could be used as nexthop for the address in local address TLV. Receivers consolidate state from various TLV and pass on BGP for the session opening. An implementation could only notify if the state change from previous reported state to bgp or the configuration sequence number changes from the receiver. How bgp uses this information is beyond the scope of the document.¶

9. References