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.cnAlef EdgeUSAxufeng.liu.ietf@gmail.comBGP is used to distribute a binding to a node.
The binding includes a binding SID and
a path represented by a list of SIDs.
This document describes extensions to BGP for distributing
the information about the binding to a protecting node.
For an SR path via the node with the binding SID,
when the node fails,
the protecting node such as the upstream neighbor
on the path uses the information
to protect the binding SID of the failed node.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [] [] when, and
only when, they appear in all capitals, as shown here.
specifies how BGP may be used to distribute a
Segment Routing (SR) Policy to a node in a network.
An SR Policy may contain a binding, which includes
a binding SID and a path
represented by a list of SIDs.
After a BGP as a controller distributes the binding to the node,
the node forwards the packet with the binding SID according to
the first SID in the list.
It replaces the binding SID in the packet with the list of SIDs and
forwards the packet using the FIB entry for the top SID
(i.e., the first SID) in the packet.When the node fails,
suppose that a protecting node (e.g., the upstream neighbor as PLR)
of the node has the corresponding binding protection information
for protecting the binding SID of the node.
The information includes the binding
SID, the list of SIDs and an identifier of the node.
After the upstream neighbor as PLR detects the failure of the node,
for a packet with the node SID of the failed node received,
it protects the binding SID of the failed node.
It replaces the binding SID in the packet with the list of SIDs,
forwards the packet without going through the failed node
towards the top SID (i.e., the first SID, assuming it is a node SID
for simplicity here).
The requirement for distributing the binding protection
information to a protecting node
and how a protecting node protect the binding SID of the failed node
are
out of scope of this document and
described in
and .
(Note: the second
reference will be removed after the first one includes enough text
for protecting binding SIDs of a node).
This document specifies some procedures and extensions
to BGP for distributing the information
to a protecting node that may protect the failed node.
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.
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 ID sub-TLV
indicating the ID of the Protected Node.When an 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 protection information. 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 an 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.
The format of Protected Node ID sub-TLV
is illustrated below. Its value (1) indicates the type of
Protected Node ID sub-TLV.Its value (4) indicates the length
of the value field of the sub-TLV is 4. 4-octet field
contains the identifier (ID) of
the Protected Node.When a BGP sends a binding
to node N
for a SR path going through node N,
the BGP distributes the corresponding binding
protection information to the possible protecting nodes.
The upstream neighbor of node N along the SR path
is a protecting node.
If node N is a loose hop in the SR path with N's node ID,
the upstream node having its node SID next to N's node ID in the SR path
and
the neighbors of node N are the possible protecting nodes.
After sending the binding to node N and
distributing the corresponding binding protection information
to the protecting nodes,
if BGP removes the binding from node N,
it removes the corresponding binding protection information
from the protecting nodes.
If BGP changes the binding in node N,
it changes the corresponding binding protection information
in the protecting nodes.
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:
AcknowledgmentsThe authors would like to thank
Andrew Stone, Robert Raszuk, Ketan Talaulikar, Donald Eastlake,
Zhibo Hu, Haibo Wang, Yao Liu, Changwang Lin, Jie Dong and Zhenqiang Li
for their comments to this work.