BGP Extensions for
IDs AllocationFutureweiBoston, MAUSAHuaimo.chen@futurewei.comHuaweiHuawei Bld., No.156 Beiqing Rd.Beijing100095Chinalizhenbin@huawei.comChina MobileNo. 29 Finance Street, Xicheng DistrictBeijing100029P.R. Chinali_zhenqiang@hotmail.comCasa SystemsUSAyfan@casa-systems.com Verizon USAmehmet.toy@verizon.comFujitsuUSAliulei.kddi@gmail.com
Routing
IDR Working Group
This document describes extensions to the BGP for IDs allocation.
The IDs are SIDs for segment routing (SR), including SR for IPv6 (SRv6).
They are distributed to their domains if needed.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
RFC 2119.
In a network with a central controller,
the controller has the link state information of the network,
including the resource such as traffic enginerring and SIDs information.
It is valuable for the controller to allocate and manage
the resources including SIDs of the network in a centralized way,
especially for the SIDs representing network resources
.
When BGP as a controller allocates an ID, it is natural and beneficial
to extend BGP to send it to its corresponding network elements.
PCE may be extended to send IDs to their corresponding network
elements after the IDs are allocated by a controller.
However, when BGP is already deployed in
a network, using PCE for IDs will need to deploy an extra protocol
PCE in the network.
This will increase the CapEx and OpEx.
Yang may be extended to send IDs to their corresponding network
elements after the IDs are allocated by a controller.
However, Yang progress may be slow. Some people may not like this.
There may not be these issues when BGP is used to send IDs.
In addition, BGP may be used to distribute IDs into their domains
easily when needed. It is also fit for the dynamic and static allocation
of IDs.
This document proposes extensions to the BGP for sending Segment
Identifiers (SIDs) for segment routing (SR) including SRv6
to their corresponding network elements after SIDs are allocated
by the controller.
If needed, they will be distributed into their network domains.
The following terminology is used in this document.
Segment Routing.SR for IPv6Segment Identifier.Indirection Identifier.Segment Routing Path.Segment Routing Tunnel.Route Reflector.MPLS Path Programming.Node or Adjacency Identifier.Traffic Engineering Database.A new AFI and SAFI are defined:
the Identifier AFI and the SID SAFI
whose codepoints are to be assigned by IANA.
A few new NLRI TLVs are defined for the new AFI/SAFI,
which are Node, Link and Prefix SID NLRI TLVs.
When a SID for a node, link or prefix is allocated by the
controller, it may be sent to a network element in a UPDATE
message containing a MP_REACH NLRI with the new AFI/SAFI and
the SID NLRI TLV.
When the SID is withdrawn by the controller,
a UPDATE message containing a MP_UNREACH NLRI with the new AFI/SAFI and
the SID NLRI TLV may be sent to the network element.
The Node SID NLRI TLV
is used to represent the IDs such as SID associated with a node.
Its format is illustrated in the Figure below,
which is similar to the corresponding one defined
in .
Where:
It is to be assigned by IANA. It is the length of the value field in bytes. 4/16 octet value indicates an IPv4/IPv6 peer.
When receiving a UPDATE message, a BGP speaker processes it only
if the peer IP is the IP address of the BGP speaker or 0.defined
in ,
can be reused.
Sub-TLVs may be some of the followings:
It contains the
Segment Routing Global Base (SRGB) range(s) allocated for the node.
The SR Local Block (SRLB) TLV contains the range(s) of SIDs/labels
allocated to the node for local SIDs.
A new TLV, called SRv6 Node SID TLV, contains an SRv6 SID
and related information.
A new TLV, called SRv6 Locator TLV, contains an SRv6 locator
and related information.The format of SRv6 SID Node TLV is illustrated below. TBD1 for SRv6 Node SID TLV
is to be assigned by IANA. Variable. 1 octet. No flags are defined now. 2 octets.
The function associated with SRv6 SID. 16 octets.
IPv6 address representing SRv6 SID.MUST be set to 0 while sending
and ignored on receipt.
SRv6 node SID inherits the topology and algorithm from its
locator.
The format of SRv6 locator TLV is illustrated below. TBD2 for SRv6 Locator TLV
is to be assigned by IANA. Variable. Multitopology Identifier as defined in
. 1 octet. Associated algorithm. 1 octet.
As described in
. 4 octets.
As described in . 1 octet.
Number of bits in the Locator field (1 to 128). 1 to 16 octets.
SRv6 Locator encoded in the minimum number of octets for
the given Locator-Size.MUST be set to 0 while sending
and ignored on receipt.
The Link SID NLRI TLV
is used to represent the IDs such as SID associated with a link.
Its format is illustrated in the Figure below,
which is similar to the corresponding one defined
in .
Where:
It is to be assigned by IANA. It is the length of the value field in bytes. 4/16 octet value indicates an IPv4/IPv6 peer. defined
in ,
can be reused.
The Sub-TLVs may be some of the followings:
It contains the
Segment Identifier (SID) allocated for the link/adjacency. It contains the
Segment Identifier (SID) allocated for the adjacency/link
to a non-DR router on a broadcast, NBMA, or hybrid link.
A new TLV, called SRv6 Adj-SID TLV, contains an SRv6 Adj-SID and
related information.
A new TLV, called SRv6 LAN Adj-SID TLV, contains an SRv6 LAN Adj-SID and
related information.The format of an SRv6 Adj-SID TLV is illustrated below.
TBD3 for SRv6 Adj-SID TLV
is to be assigned by IANA. Variable. 1 octet. The value represents the
weight of the SID for the purpose of load balancing. 1 octet. Associated algorithm. 2 octets. Three flags are defined in
. 2 octets.
The function associated with SRv6 SID. 16 octets.
IPv6 address representing SRv6 SID.MUST be set to 0 while sending
and ignored on receipt.The format of an SRv6 LAN Adj-SID TLV is illustrated below.
TBD4 for SRv6 LAN Adj-SID TLV
is to be assigned by IANA. Variable. 1 octet. The value represents the
weight of the SID for the purpose of load balancing. 1 octet. Associated algorithm. 2 octets. Three flags B, S and P are defined in
.
Flag O set to 1 indicating OSPF neighbor Router ID of 4
octets, set to 0 indicating IS-IS neighbor System ID of 6
octets. 2 octets.
The function associated with SRv6 SID. 16 octets.
IPv6 address representing SRv6 SID.MUST be set to 0 while sending
and ignored on receipt.
The Prefix SID NLRI TLV
is used to represent the IDs such as SID associated with a prefix.
Its format is illustrated in the Figure below,
which is similar to the corresponding one defined
in .
Where:
It is to be assigned by IANA. It is the length of the value field in bytes. 4/16 octet value indicates an IPv4/IPv6 peer.defined
in ,
can be reused.Sub-TLVs may be some of the followings:
It contains the
Segment Identifier (SID) allocated for the prefix. It contains a range of prefixes and
the Segment Identifier (SID)s allocated for the prefixes.It is necessary to negotiate the capability to support BGP
Extensions for sending and receiving Segment Identifiers (SIDs).
The BGP SID
Capability is a new BGP capability . The
Capability Code for this capability is to be specified by the IANA.
The Capability Length field of this capability is variable. The
Capability Value field consists of one or more of the following
tuples:The meaning and use of the fields are as follows:Address Family Identifier (AFI): This field is the same as the one
used in .Subsequent Address Family Identifier (SAFI): This field is the same
as the one used in .Send/Receive: This field indicates whether the sender is (a)
willing to receive SID from its peer
(value 1), (b) would like to send SID to
its peer (value 2), or (c) both (value 3) for the <AFI,
SAFI>.This document requests assigning a new AFI in the registry
"Address Family Numbers" as
follows:
This document requests assigning a new SAFI in the registry
"Subsequent Address Family Identifiers (SAFI) Parameters" as
follows:
This document defines a new registry called "SID NLRI TLVs".
The allocation policy of this registry is "First Come First
Served (FCFS)" according to .
Following TLV code points are defined:
This document requests assigning a code-point from the registry
"BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs"
as follows:
Protocol extensions defined in this document do not
affect the BGP security other than those as discussed
in the Security Considerations section of
.The authors would like to thank
Eric Wu,
Robert Raszuk, Zhengquiang Li,
and Ketan Talaulikar
for their valuable suggestions and comments on this draft.