Segment Routing for Unaffiliated BFD
Echo FunctionHuaweimach.chen@huawei.comHuaweiwxxuan@huawei.comChina Mobilejiangwenying@chinamobile.comChina Mobileliuyisong@chinamobile.comHuaweiifocus.chen@huawei.com
Routing Area
Source Packet Routing in NetworkingSR, BFD, EchoDraftThis document describes how to leverage Segment Routing (SR) to
ensure that the Unaffiliated BFD (U-BFD) Echo packets must reach the
remote system before being looped back to the local system. This enables
that U-BFD works not only for one hop scenario but for multiple hops
scenario as well.In addition, this document also defines a way to explicitly specify
the loop back path of the U-BFD Echo packets. This is useful in the case
where the forward and reverse path of the Echo packets are required to
follow the same path.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 when, and only when, they
appear in all capitals, as shown here.BFD Echo function was originally defined in
and , where the remote system is required to
loop the BFD Echo packets back to the local system. To support BFD Echo
Function, some negotiations between the local system and remote system
are needed, and both the local and remote system need to maintain the
BFD session state.Unaffiliated BFD Echo Function (U-BFD) is defined in . Where the destination IP
address of the BFD Echo packets is set to one of the IP addresses of the
local system. Therefore, the Echo packets can be automatically looped
back (through normal IP forwarding) by the remote system to the local
system. With U-BFD, the remote system does not need to support any BFD
related functions and maintain any session states. This further
simplifies the BFD Echo Function process at the remote system hence
greatly increases scalability.But, the U-BFD works when there is only one hop between the local
system and remote system. Otherwise, the Echo packets will be
prematurely looped back by an intermediate node, and the Echo packets
will not reach the remote system. This may result in false negative
issue. Take the following figure (Figure 1) as an example, if the U-BFD
is expected to monitor the path between node A and node C, node A (as
the local system) sets the destination IP to itself and sends the Echo
packets to node B. Since node B has the route to node A, the Echo
packets will be directly forwarded back to node A. If there is a failure
on the path between node B and node C, obviously, the U-BFD session
cannot detect it.In addition, in some scenarios, for example, mobile backhaul network,
where the forward and reverse direction of a path are required to along
the same path. When apply BFD in mobile backhaul network, it also
expects that the BFD control packets in both directions follow the same
path, otherwise, it may result in false positive issue. Take the
following figure (Figure 2) as an example, there are two paths (A-B-C,
A-D-C) between node A and node C. Assuming that it expects to monitor
the path A-B-C by using BFD, where node A is the local system and node C
is the remote system. If node C chooses path C-D-A to send the Echo
packets, when a failure occurs on path C-D-A, node A (the local system)
may not receive the BFD packets and consider that path A-B-C is failed.
But actually path A-B-C is working.To solve the above issues, this document describes how to leverage
the Segment Routing (SR) to ensure that the
U-BFD Echo packets must reach the remote system before being looped
back. This enables that U-BFD Echo Function works not only for one hop
scenario but for multiple hops scenario. In addition, by using SR policy
, the loop back
path of the Echo packets can be specified as required. This is useful in
the case where the forward and loop back path of the Echo packets are
required to follow the same path.When using U-BFD to monitor a path, the U-BFD echo packets are
constructed as specified in , then the U-BFD echo packets
are encapsulated in an SR tunnel and sent to the remote system. It needs
to make sure that the SR tunnel and the path being monitored follow the
same path and share the same fate, otherwise the UP/Down state can not
reflect the health of the path being monitored. This can be satisfied if
the path itself is an SR path, where the U-BFD echo packets, just as
other data traffic, are transmitted over the SR tunnel to the remote
system. When the packet arrives the remote system, the SR encapsulation
(e.g, MPLS Label Stack, or IPv6 Header with/without SRH) is removed, the
inner IP header is exposed. Since the destination IP address of the
inner header is one of the routable IP addresses of the local system,
the echo packet will be forwarded back to the local system via IP
routing.If the path is an pure IP path, SR over IP
or SRv6 Best Effort (BE) can be used to tunnel the U-BFD echo packets to
the remote system. Once the packet reaches the remote system, the remote
system decapsulates the echo packet and forwards it back to the local
system based on the inner header.In some cases, for example, mobile backhaul network, bidirectional
paths are often used. And in general, the forward and reverse direction
of the bidirectional path are required to follow the same path hence to
share the same fate. Therefore, when apply U-BFD to monitor such a
bidirectional path, the forward and reserve path the U-BFD echo need to
follow the same path as well.In the case of SR, is normally used to
implement bidirectional path. To ensure that the U-BFD Echo packets can
reach the remote system before looping back to the local system, the SR
policy MUST have a candidate path that is associated with a
Segment-List, and the Segment-List MUST include a SID that identifies
the remote system. That means the U-BFD Echo packets will be tunneled by
the SR policy to the remote system, and then looped back.To specify the loopback path, a series of SIDs or a Binding SID
(BSID) that is associated with the loopback path MUST be added to the
SID stack of the U-BFD Echo packets. This can be done through the
following ways:Given the topology in Figure 2, the SR policy can be modeled as
below:Not explicitly specify the reserve path: The U-BFD Echo packets are transmitted to the remote
system according the SR policy. When the Echo packets reach the
remote system, they will be decapsulated and then forwarded back to
the local system according to inner IP header.Specify the reverse path by carrying a Reverse Binding Segment
Identifier (R-BSID):Two new attributes, which are referred to as Local BSID
(L-BSID) and Remote BSID (R-BSID), are introduced to a candidate
path. Here, the L-BSID or R-BSID is a BSID that correlates to a
specific SID List rather a candidate path. The L-BSID is a local
BSID on the headend, in the above example, it identifies the
SID-List <B, C>. The R-BSID identifies another corresponding
SID list <B, A> that is deployed on the endpoint (Node C) and
has the same path and share the same fate with SID-list <B,
C>. SID List <B, C> and SID List <B, A> form a
bidirectional SR path. With this, a SID stack <B, C, R-BSID>
will be attached to the U-BFD echo packets, the SID B and C will
take the echo packets to the remote system, the R-BSID will bring
the echo packets back to the local system.Specify the reverse path by explicitly carrying the SID list of
the reverse path:A new attribute, Reverse SID-List, is introduced to a
candidate path, it corresponds to a SID-List of the candidate path.
In the above example, the SID-List <B, C> and Reverse SID-List
<B, A> form a bidirectional path. With this, a SID stack
<B, C, B, A> will be attached to the U-BFD echo packets, th
SID B and C will take the echo packets to the remote system, and the
SID B and A will bring the back to the local system.With the current SR policy, a BSID corresponds to a candidate path
that may have multiple SID Lists. In the case of bidirectional SR path,
the forward or reverse path corresponds to a specific SID List. In order
to identify a SID List with a SID, the straightforward idea is to define
a BSID to for SID list. A bidirectional SR path correlates to two SID
Lists: the forward SID List and the reverse SID List. Therefore, two
BSIDs (L-BSID and R-BSID) need to be defined for a bidirectional SR path
to identify the corresponding SID list.An information model of a SR policy with the L-BSID and R-BSID is as
follows:The POL1 has two candidate paths, CP1 and CP2. Each has a
SID-List, a Local BSID (L-BSID) and a Reverse BSID (R-BSID). The L-BSID
corresponds to the SID List (e.g., L-BSID-1 corresponds to SID-List
<SID11...SID1i>). The R-BSID corresponds a SID List of a candidate
path of a policy that is deployed on the endpoint (E1), as following.
Assume that the SID-List1 of POL1 and the SID-List1 of POL2 form a
bidirectional SR path. For policy POL1, the R-BSID-1 is the same as the
L-BSID-1' of policy POL2; and the R-BSID-1' of POL2 is the same as the
L-BSID-1 of policy POL1.Therefore, to deploy such a policy, it needs to know the
R-BSID of the corresponding reverse SID List. It assumes that a
controller will learn the L-BSID of each SID list and is responsible for
the configuration of SR policy on both the headend and endpoint of the
SR policies.The corresponding BGP or PECP extensions in support of SR policy with
BSID for SID List will be defined in future version.This document makes no request of IANA.This document does not introduce additional security requirements and
mechanisms other than the ones described in and .Many thanks for the Changwang Lin for his valuable comments.The following people have substantially contributed to this
document: