BGP for Mirror BindingFutureweiBoston, MAUSAhuaimo.chen@futurewei.com Orange Francebruno.decraene@orange.comVerizon13101 Columbia PikeSilver SpringMD 20904USA 301 502-1347gyan.s.mishra@verizon.comCasa SystemsUSAyfan@casa-systems.comChina TelecomBeiqijia Town, Changping DistrictBeijing102209Chinawangaj3@chinatelecom.cnIBM CorporationUSAxufeng.liu.ietf@gmail.comBGP is used to distribute a binding SID with a list of SIDs
to a node.
This document describes extensions to
BGP for distributing
the binding SID with the list of SIDs and an identifier of the node.
When detecting the failure of the node, an neighbor of the node
protects the binding SID of the failed node.
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.
specifies how BGP may be used to distribute a
Segment Routing (SR) Policy to a network node.
An SR Policy is an
ordered list of segments (i.e., instructions) that represent a
source-routed policy.
An SR Policy consists of one or more candidate
paths, each consisting of one or more segment lists.
An SR Policy may contain a binding SID associated with a path
represented by a segment list (i.e., a list of SIDs).
After a BGP as a controller distributes an SR policy containing
a binding SID associated with a list of SIDs to a network node,
each neighbor of the node needs the information about the binding SID
for protecting the binding SID of the node when the node fails.
The information includes the binding SID, the list of SIDs and
the identifier (ID) of the node.
This document proposes some procedures and extensions
to BGP for distributing the information.
This section defines a new Binding Protection sub-TLV
under a Tunnel Encapsulation Attribute TLV of type 15
(i.e., SR Policy TLV).
A Tunnel Encapsulation Attribute contains a Tunnel Encapsulation
Attribute TLV.
The structure containing a Binding Protection
sub-TLV is shown below.
A Binding Protection sub-TLV contains the information
about a binding SID of a network node for a neighbor of the node to
protect the Binding SID of the node when the neighbor detects the
failure of the node.
The format of a Binding Protection sub-TLV is
illustrated below.
Its value (TBD1) is to be assigned by IANA.It is variable.1 octet of flags. No flags is defined now.
MUST be set to zero by the sender
and MUST be ignored by the receiver. This field contains
the sub-TLV below to indicate the node to be protected
(i.e., the protected node).
Protected Node BGP ID sub-TLV
indicating the BGP ID of the Protected Node.
When a SR Policy (i.e., SR Policy TLV) contains a binding SID and a
path with a protected node, the SR policy is for distributing the
binding information of the node for protecting the binding SID of the
node when the node fails (binding protection for short). The binding
SID is encoded by a Binding SID sub-TLV or SRv6 Binding SID sub-TLV,
the path is encoded by a Segment List Sub-TLV, and the node is
encoded by a Binding Protection sub-TLV.
When a SR Policy contains a binding SID and a path without a
protected node, the SR policy is for replacing the Binding SID with
the path (i.e., the list of SIDs) when the node receives a packet
with the Binding SID (binding for short).
The format of Protected Node BGP ID sub-TLV
is illustrated below. Its value (1) indicates the type of
Protected Node BGP ID sub-TLV.Its value (4) indicates the length
of the value field of the sub-TLV is 4. 4-octet field
contains the BGP identifier (ID) of
the Protected Node.When a BGP sends a piece of binding information to node N
in a first Update message, the BGP sends the corresponding binding
protection information to each neighbor of node N in a second
Update message. The first message contains a first SR Policy
carried in MP_REACH_NLRI. The first SR Policy includes a binding SID
and a path but does not include node N as a protected node.
The second message contains a second SR Policy carried in MP_REACH_NLRI.
The second SR Policy includes the binding SID, the path and node N
as a protected node.
After a BGP sends the binding information to node N,
if BGP removes the binding information from node N through sending
a third Update message to node N, BGP removes the corresponding
binding protection information from each neighbor of node N through
sending a fourth Update message to the neighbor. The third message
contains a third SR Policy carried in MP_UNREACH_NLRI.
The third SR Policy includes the binding SID and the path
but does not include node N as a protected node. The fourth message
contains a fourth SR Policy carried in MP_UNREACH_NLRI.
The fourth SR Policy includes the binding SID, the path and
node N as a protected node.
After a BGP sends the binding information to node N,
if the BGP changes the binding information in node N through
sending a fifth Update message to node N, BGP changes the
corresponding binding protection information in each neighbor
of node N through sending a sixth Update message to the neighbor.
The fifth message contains a fifth SR Policy carried in MP_REACH_NLRI.
The fifth SR Policy includes the binding SID and a (changed)
path but does not include node N as a protected node.
The sixth message contains a sixth SR Policy carried in
MP_REACH_NLRI. The sixth SR Policy includes the binding SID,
the (changed) path and node N as a protected node.
Protocol extensions defined in this document do not
affect the BGP security other than those as discussed
in the Security Considerations section of
.This document requests assigning a new sub-TLV
in the registry "BGP Tunnel Encapsulation Attribute sub-TLVs"
as follows: