Network Working Group Z. Li
Internet-Draft Huawei Technologies
Intended status: Standards Track L. Ou
Expires: January 7, 2016 Y. Luo
China Telcom Co., Ltd.
S. Zhuang
N. Wu
Huawei Technologies
July 06, 2015
BGP FlowSpec Extensions for Routing Policy Distribution (RPD)
draft-li-idr-flowspec-rpd-00
Abstract
This document describes a mechanism to use BGP Flowspec address
family [RFC5575] as routing-policy distribution protocol. This
mechanism is called BGP FlowSpec Extensions for Routing Policy
Distribution (BGP FS RPD).
Requirements Language
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 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2016.
Li, et al. Expires January 7, 2016 [Page 1]
Internet-Draft BGP FS RPD July 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Routing Policies . . . . . . . . . . . . . . . . . . . . 3
1.2. BGP FlowSpec . . . . . . . . . . . . . . . . . . . . . . 4
1.3. BGP FlowSpec Extensions for Routing Policy Distribution . 4
2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 5
3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5
3.1. FlowSpec Traffic Actions for Routing Policy Distribution 5
3.2. BGP Policy Attribute . . . . . . . . . . . . . . . . . . 6
3.2.1. Match Fields Format . . . . . . . . . . . . . . . . . 6
3.2.2. Action Fields Format . . . . . . . . . . . . . . . . 8
3.3. Capability Negotiation . . . . . . . . . . . . . . . . . 9
4. Applications . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Outbound Traffic Control . . . . . . . . . . . . . . . . 9
4.2. Inbound Traffic Control . . . . . . . . . . . . . . . . . 12
5. Additional Contributors . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
On a traditional IP network, devices calculate their respective paths
in a dynamic and distributed manner. The entire network is divided
into multiple autonomous systems (ASs), and an Interior Gateway
Protocol (IGP) runs on the devices within each AS. The IGP enables
devices within an AS to obtain the intra-AS network topology and use
the same algorithm to calculate routes. Devices in different ASs use
Border Gateway Protocol (BGP) to exchange routes. If a link or
device fails, the IP network layer triggers route convergence to
Li, et al. Expires January 7, 2016 [Page 2]
Internet-Draft BGP FS RPD July 2015
protect data traffic. However, if you want to manually optimize
traffic paths on a traditional IP network, you will encounter the
following difficulties:
Traffic can only be adjusted device by device. All routers that the
traffic traverses need to be configured. The configuration workload
is heavy. The operation is not only time consuming but also prone to
misconfiguration for Service Providers.
The routing policies used to control network routes are complex,
posing difficulties to subsequent maintenance, high maintenance
skills are required.
Hence, an automatic mechanism for setting up routing policies is
desirable which can simplify the complexity of routing policies
configuration.
1.1. Routing Policies
Routing policies are used to filter routes and control how routes are
received and advertised. If route attributes, such as reachability,
are changed, the path along which network traffic passes changes
accordingly.
When advertising, receiving, and importing routes, the router
implements certain policies based on actual networking requirements
to filter routes and change the attributes of the routes. Routing
policies serve the following purposes:
o Control route advertising: Only routes that match the rules
specified in a policy are advertised.
o Control route receiving: Only the required and valid routes are
received. This reduces the size of the routing table and improves
network security.
o Filter and control imported routes: A routing protocol may import
routes discovered by other routing protocols. Only routes that
satisfy certain conditions are imported to meet the requirements of
the protocol.
o Modify attributes of specified routes Attributes of the routes:
that are filtered by a routing policy are modified to meet the
requirements of the local device.
o Configure fast reroute (FRR): If a backup next hop and a backup
outbound interface are configured for the routes that match a routing
policy, IP FRR, VPN FRR, and IP+VPN FRR can be implemented.
Li, et al. Expires January 7, 2016 [Page 3]
Internet-Draft BGP FS RPD July 2015
Routing policies are implemented using the following procedures:
1) Define rules: Define features of routes to which routing policies
are applied. Users define a set of matching rules based on different
attributes of routes, such as the destination address and the address
of the router that advertises the routes.
2) Implement the rules: Apply the matching rules to routing policies
for advertising, receiving, and importing routes.
1.2. BGP FlowSpec
BGP FlowSpec is defined in [RFC 5575]. This RFC describes a new NLRI
that allows to convey flow specifications and traffic Action/Rules
associated (rate-limiting, redirect, remark ...). BGP Flow
specifications are encoded within the MP_REACH_NLRI and
MP_UNREACH_NLRI attributes. Rules (Actions associated) are encoded
in Extended Community attribute. The BGP Flow Specification function
allows BGP Flow Specification routes that carry traffic policies to
be transmitted to BGP Flow Specification peers to control attack
traffic.
BGP FlowSpec leverages the BGP Control Plane to simplify the
distribution of filter rules, new filter rules can be injected to all
BGP peers simultaneously without changing router configuration. The
typical application of BGP Flow-spec is to automate the distribution
of traffic filter lists to routers for DDOS mitigation.
1.3. BGP FlowSpec Extensions for Routing Policy Distribution
BGP FlowSpec address family [RFC5575] is used to install Flow based
filters to filter unwanted data traffic. It is based on the
forwarding plane, serves forwarding. BGP FlowSpec feature allows you
to rapidly deploy and propagate filtering and policing functionality
among a large number of BGP peer routers, it can easily and
automatically push the filter update to all the BGP peer routers that
support BGP FlowSpec address family, it is a powerful tool.
Routing Policy is based on the control plane, serves routing
protocols and routing tables. Routing Policy is also a powerful
tool. Currently, Routing Policy can only be configured device by
device.
This document describes a mechanism to use BGP Flowspec address
family [RFC5575] as routing-policy distribution protocol. This
mechanism is called BGP FlowSpec Extensions for Routing Policy
Distribution (BGP FS RPD).
Li, et al. Expires January 7, 2016 [Page 4]
Internet-Draft BGP FS RPD July 2015
BGP FS RPD introduce a new BGP path attribute called BGP Policy
Attribute, it defines the matching criteria and actions for routing
policies in the BGP Policy Attribute.
BGP FS RPD uses the Destination Prefix component in the BGP FS NLRI
to define a target prefix. When a device receives a BGP FS RPD
route, it will use the target prefix containing in the BGP FS NLRI to
choose the matching routes, in most case, a prefix will have one more
matching routes.
When the matching routes are selected, the routing policies carrying
in the BGP FS RPD route wiil be applied to them.
2. Definitions and Acronyms
BGP Flow Specification route: BGP Flow Specification routes are
defined in RFC 5575. Each BGP Flow Specification route contains BGP
Network Layer Reachability Information (NLRI) and Extended Community
Attributes, which carry traffic filtering rules and actions to be
taken on filtered traffic.
BGP Flow Specification peer relationship: A BGP Flow Specification
peer relationship is established between the device that generates
BGP Flow Specification routes and each network ingress that will
transmit the BGP Flow Specification routes. After receiving the BGP
Flow Specification routes, the peer delivers preferred BGP Flow
Specification routes to the forwarding plane. The routes are then
converted into traffic policies that control attack traffic.
ACL:Access Control List
BGP: Border Gateway Protocol
FS: Flow Specification
PBR:Policy-Based Routing
RPD: Routing Policy Distribution
VPN: Virtual Private Network
3. Protocol Extensions
3.1. FlowSpec Traffic Actions for Routing Policy Distribution
The traffic-action extended community consists of 6 bytes of which
only the 2 least significant bits of the 6th byte (from left to
right) are currently defined in [RFC5575]. Terminal Action (bit 47)
Li, et al. Expires January 7, 2016 [Page 5]
Internet-Draft BGP FS RPD July 2015
and Sample (bit 46) defines in [RFC5575], this document defines Route
Policy Distribution Flag(Bit 45).
The Flow Specification Traffic Actions for Routing Policy
Distribution:
40 41 42 43 44 45 46 47
+---+---+---+---+---+---+---+---+
| reserved | R | S | T |
+---+---+---+---+---+---+---+---+
Figure 1: FlowSpec Traffic-action
Route Policy Distribution Flag(Bit 45): When this bit is set, the
corresponding filtering rules will be used as Route Policy.
3.2. BGP Policy Attribute
This document defines and uses a new BGP attribute called the "BGP
Policy attribute". This is an optional BGP attribute. The format of
this attribute is defined as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Match fields (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Action fields (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: BGP Policy Attribute
Match fields: Match Fields define the matching criteria for the BGP
Policy Attribute.
Action fields: Action fields define the action being applied to the
target route.
3.2.1. Match Fields Format
Match Fields define the matching criteria for the BGP Policy
Attribute.
Li, et al. Expires January 7, 2016 [Page 6]
Internet-Draft BGP FS RPD July 2015
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Match Type (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Sub-TLVs (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sub-TLVs (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Match Fields Format
Match Type:
0: Permit, specifies the permit mode of a match rule. If a route
matches the matching criteria of the BGP Policy Attribute, the
actions defined by the Action fields of the BGP Policy Attribute are
performed. If a route does not match the matching criteria for the
BGP Policy Attribute, then nothing needs to do with this route.
1: Deny, specifies the deny mode of a match rule. In the deny mode,
If a route does not match the matching criteria of the BGP Policy
Attribute, the actions defined by the Action fields of the BGP Policy
Attribute are performed. If a route matches the matching criteria of
the BGP Policy Attribute, then nothing needs to do with this route.
Number of Sub-TLVs: The number of Sub-TLVs contain in Match fields.
The contents of Match fields are encoded as Sub-TLVs, where each TLV
has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Values (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Sub-TLVs Format
Type: The Type field contains a value of 1-65534. The values 0 and
65535 are reserved for future use.
Length: The Length field represents the total length of a given TLV's
value field in octets.
Values: The Value field contains the TLV value.
Li, et al. Expires January 7, 2016 [Page 7]
Internet-Draft BGP FS RPD July 2015
Supported format of the TLVs can be:
Type 1: IPv4 Neighbor
Type 2: IPv6 Neighbor
Type 3: ASN List
...
To be added in later versions.
3.2.2. Action Fields Format
Action fields define the action being applied to the targeted route.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action Type (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Action Values (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Action Fields Format
Action Type: The Action Type field contains a value of 1-65534. The
values 0 and 65535 are reserved for future use.
Action Length: The Action Length field represents the total length of
the Action Values in octets.
Action Values: The Action Values field contain parameters of the
action.
Supported format of the TLVs can be:
Type 1: Route-Preference
Type 2: Route-Prepend-AS
...
To be added in later versions.
Li, et al. Expires January 7, 2016 [Page 8]
Internet-Draft BGP FS RPD July 2015
3.3. Capability Negotiation
It is necessary to negotiate the capability to support BGP FlowSpec
Extensions for Route Policy Distribution (RPD). The BGP FS RPD
Capability is a new BGP capability [RFC5492]. 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:
+--------------------------------------------------+
| Address Family Identifier (2 octets) |
+--------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+--------------------------------------------------+
| Send/Receive (1 octet) |
+--------------------------------------------------+
Figure 6: BGP FS RPD Capability
The meaning and use of the fields are as follows:
Address Family Identifier (AFI): This field is the same as the one
used in [RFC4760].
Subsequent Address Family Identifier (SAFI): This field is the same
as the one used in [RFC4760].
Send/Receive: This field indicates whether the sender is (a) willing
to receive Route Policies via BGP FLowSpec from its peer (value 1),
(b) would like to send Route Policies via BGP FLowSpec to its peer
(value 2), or (c) both (value 3) for the <AFI, SAFI>.
4. Applications
4.1. Outbound Traffic Control
Figure 7 shows the multiple transit providers scenario. For Network
1, it has n entries/exits that respectively connect to transit
network N1, N2 and Nn. And between Network 1 and each transit
network, there is one or more links. Different link has different
cost/price, bandwidth, delay/loss attributes.
For this multiple extry/exit scenario, it has the following
requirements:
o Choose the proper extry/exit based on link price and/or service
type;
Li, et al. Expires January 7, 2016 [Page 9]
Internet-Draft BGP FS RPD July 2015
o Dynamically adjust the extry/exit based on link load and/or link
price;
/----\ |------------|
| N1 |---| |
L1 / \----/ | |
---------------- / / | |
/// \\\ / / | |
/ ------ /\ /L3 | |
| |IGW1|--+ | / | |
| ------------ ------ \|/ | |
| |Policy | /\ | |
| |Controller| / |\ | | Route-Advertising
| ------------ / | \L2 | | <-------
| ------/ | \ /----\ | |
| Network 1 |IGW2|----+---| N2 |--| ... |------| Prefix1
| ------ L4 | \----/ | |
| ----- | | |
| |PE1| ... | ... | |
| ----- ------ | | |
| |IGWn|--+ | | |
| ------ \| | |
| |\ | |
\\\ /// \ | |
---------------- \ /----\ | |
| Nn |---| |
\----/ |------------|
-----> Traffic to Prefix1
PE1 acts as an Ingress Router
EBGP peering:
L1: IGW1 with N1; L2: IGW1 with N2; L3: IGW2 with N1; L4: IGW2 with N2
Figure 7: Inbound Route Control / Outbound Traffic Control
Outbound traffic control adjusts the transmission paths of outbound
traffic from the ISP network to ensure that the traffic is evenly
shared among links between IGWs and Transit Providers networks and
the bandwidth usage of each link is below the specified threshold.
In outbound traffic control scenario, if the bandwidth usage of a
link exceeds the specified threshold, the Policy Controller
automatically identifies which traffic needs to be scheduled and the
Policy Controller automatically calculates traffic control paths
based on network topology and traffic information.
For example:
Li, et al. Expires January 7, 2016 [Page 10]
Internet-Draft BGP FS RPD July 2015
To ensure even traffic sharing, the outbound traffic destined for
Prefix1 needs to be scheduled to link IGW2 -> N1 for transmission.
The Policy Controller sends a BGP FS RPD route to IGW2, the route
carries:
1) Prefix1 in the Destination Prefix component of the BGP FS NLRI;
2) Flow Specification Traffic Action Extended Community with the
Route Policy Distribution Flag(Bit 45) set. When this bit is set,
the corresponding filtering rules will be used as Routing Policies.
3) BGP Policy Attribute:
o Match Type: 1, Permit
o IPv4 Neighbor Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer N1
o Action Type: Route-Preference
IGW2 processes the received BGP FS RPD route as follows:
1) IGW2 gets the target prefix Prefix1 from the Destination Prefix
component in the BGP FS NLRI of the BGP FS RPD route;
2) IGW2 identifies the Route Policy Distribution Flag carrying in the
Flow Specification Traffic Action Extended Community, then IGW2 knows
that the corresponding filtering rules will be used as Routing
Policies.
3) IGW2 uses the target prefix Prefix1 to choose the matching routes,
in this case, the prefix Prefix1 has two more routes:
Prefix Next-Hop Local BGP Speaker Remote BGP Peer
Prefix1 N1 IGW2 N1
Prefix1 N2 IGW2 N2
...
4) IGW2 gets the matching criteria from the BGP Policy Attribute:
Local BGP Speaker IGW2, Remote BGP Peer N1;
5) IGW2 gets the action from the BGP Policy Attribute: Route-
Preference;
So IGW2 chooses the BGP route received from N1 (rather than N2) as
the best route and the outbound traffic destined for Prefix1 can be
scheduled to link IGW2 -> N1 for transmission.
Li, et al. Expires January 7, 2016 [Page 11]
Internet-Draft BGP FS RPD July 2015
4.2. Inbound Traffic Control
Inbound traffic control adjusts the transmission paths of traffic
bound for the IP core network to ensure that the traffic is evenly
shared among links between Transit Networks and IGWs and the
bandwidth usage of each link is below the specified threshold.
/----\ |------------|
| N1 |---| |
L1 / \----/ | |
---------------- / / | |
/// \\\ / / | |
/ ------ /\ /L3 | |
| |IGW1|--+ | / | |
| ------------ ------ \|/ | |
| |Policy | /\ | |
| |Controller| / |\ | | Traffic to Prefix2
| ------------ / | \L2 | | <-------
| ------/ | \ /----\ | |
| Network 1 |IGW2|----+---| N2 |--| ... |------| Client
| ----- ------ L4 | \----/ | |
| |PE1| | | |
| ----- ... | ... | |
| Prefix2 ------ | | |
| |IGWn|--+ | | |
| ------ \| | |
| |\ | |
\\\ /// \ | |
---------------- \ /----\ | |
| Nn |---| |
\----/ |------------|
-----> Route-Advertising
Figure 8: Outbound Route Control / Inbound Traffic Control
For example:
To ensure even traffic sharing, the traffic destined for Prefix2
needs to be scheduled to link N1 -> IGW2 for transmission.
The Policy Controller constructs a BGP FS RPD route and pushes it to
all the IGW routers, the route carries:
1) Prefix2 in the Destination Prefix component of the BGP FS NLRI;
2) Flow Specification Traffic Action Extended Community with the
Route Policy Distribution Flag(Bit 45) set. When this bit is set,
the corresponding filtering rules will be used as Routing Policies.
Li, et al. Expires January 7, 2016 [Page 12]
Internet-Draft BGP FS RPD July 2015
3) BGP Policy Attribute:
o Match Type: 2, Deny
o IPv4 Neighbor Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer N1
o Action Type: Route-Prepend-AS
o Action Value: Prepend-AS times is 5
IGW1 processes the received BGP FS RPD route as follows:
1) IGW1 gets the target prefix Prefix2 from the Destination Prefix
component in the BGP FS NLRI of the BGP FS RPD route;
2) IGW1 identifies the Route Policy Distribution Flag carrying in the
Flow Specification Traffic Action Extended Community, then IGW1 knows
that the corresponding filtering rules will be used as Routing
Policies.
3) IGW1 uses the target prefix Prefix2 to choose the matching routes,
in this case, IGW1 will choose the current best route of Prefix2;
4) IGW1 gets the matching criteria from the BGP Policy Attribute:
Local BGP Speaker IGW2, Remote BGP Peer N1;
5) IGW1 gets the action from the BGP Policy Attribute: Route-Prepend-
AS, 5 times;
IGW1 checks the matching criteria and finds that it doesn't hits the
matching criteria: Local BGP Speaker IGW2, Remote BGP Peer N1, at the
same time the Match Type is "Deny" mode, so IGW1 sends the best route
of Prefix2 to N1 with performing the Action instructions from the BGP
FS RPD route: Prepend Local AS 5 times.
IGW2 processes the received BGP FS RPD route as follows:
1) IGW2 gets the target prefix Prefix2 from the Destination Prefix
component in the BGP FS NLRI of the BGP FS RPD route;
2) IGW2 identifies the Route Policy Distribution Flag carrying in the
Flow Specification Traffic Action Extended Community, then IGW2 knows
that the corresponding filtering rules will be used as Routing
Policies.
3) IGW2 uses the target prefix Prefix2 to choose the matching routes,
in this case, IGW2 will choose the current best route of Prefix2;
Li, et al. Expires January 7, 2016 [Page 13]
Internet-Draft BGP FS RPD July 2015
4) IGW2 gets the matching criteria from the BGP Policy Attribute:
Local BGP Speaker IGW2, Remote BGP Peer N1;
5) IGW2 gets the action from the BGP Policy Attribute: Route-Prepend-
AS, 5 times;
IGW2 checks the matching criteria and finds that it hits the matching
criteria: Local BGP Speaker IGW2, Remote BGP Peer N1, but the Match
Type is "Deny" mode, so IGW2 sends the best route of Prefix2 to N1,
without performing the Action instructions from the BGP FS RPD route.
In like manner, the other IGWs will perform the same Action
instructions as IGW1.
Afterwards, client will choose the route to Prefix2 that it passes
IGW2 and N1. So the traffic destined for Prefix2 has been be
scheduled to link N1 -> IGW2 for transmission.
5. Additional Contributors
Peng Zhou
Huawei
Email: Jewpon.zhou@huawei.com
6. IANA Considerations
TBD.
7. Security Considerations
TBD.
8. Acknowledgements
The authors would like to thank xxx for their contributions to this
work.
9. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January
2007.
Li, et al. Expires January 7, 2016 [Page 14]
Internet-Draft BGP FS RPD July 2015
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, February 2009.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, August 2009.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Liang Ou
China Telcom Co., Ltd.
109 West Zhongshan Ave,Tianhe District
Guangzhou 510630
China
Email: oul@gsta.com
Yujia Luo
China Telcom Co., Ltd.
109 West Zhongshan Ave,Tianhe District
Guangzhou 510630
China
Email: luoyuj@gsta.com
Shunwan Zhuang
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Li, et al. Expires January 7, 2016 [Page 15]
Internet-Draft BGP FS RPD July 2015
Nan Wu
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: eric.wu@huawei.com
Li, et al. Expires January 7, 2016 [Page 16]