draft-ietf-idr-flowspec-nvo3-00.txt   draft-ietf-idr-flowspec-nvo3-01.txt 
IDR Working Group W. Hao
S. Zhuang
Z. Li
Internet Draft Huawei
Intended status: Standards Track R.Gu
China Mobile
Expires: November 2016 May 17, 2016
Dissemination of Flow Specification Rules for NVO3 INTERNET-DRAFT Donald Eastlake
draft-ietf-idr-flowspec-nvo3-00.txt Intended Status: Proposed Standard Weiguo Hao
Shunwan Zhuang
Zhenbin Li
Huawei Technologies
Rong Gu
China Mobil
Expires: May 15, 2018 November 16, 2017
Abstract Dissemination of NVO3 Flow Specification Rules
<draft-ietf-idr-flowspec-nvo3-01.txt>
Abstract
This draft proposes a new subset of component types to support the This draft proposes a new subset of component types to support the
NVO3 flow-spec application. NVO3 flow-spec application.
Status of this Memo Status of This Document
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the authors or the TRILL Working Group mailing list
<dnsext@ietf.org>.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as time. It is inappropriate to use Internet-Drafts as reference
reference material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
Shadow Directories can be accessed at
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice INTERNET-DRAFT NVO3 BGP Flow-Spec
Copyright (c) 2016 IETF Trust and the persons identified as the Table of Contents
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal 1. Introduction............................................3
Provisions Relating to IETF Documents 1.1 Terminology............................................5
(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 2. NVO3 Flow Specification Encoding........................6
1. Introduction ................................................ 2 3. NVO3 Flow Specification Traffic Actions.................8
2. The Flow Specification encoding for NVO3..................... 4
3. The Flow Specification Traffic Actions for NVO3.............. 6 4. Security Considerations.................................8
4. Security Considerations...................................... 6
5. IANA Considerations ......................................... 6 5. IANA Considerations.....................................9
5.1. Normative References.................................... 7
5.2. Informative References.................................. 7 Normative References......................................10
6. Acknowledgments ............................................. 8 Informative References....................................11
Acknowledgments...........................................12
Authors' Addresses........................................12
INTERNET-DRAFT NVO3 BGP Flow-Spec
1. Introduction 1. Introduction
BGP Flow-spec is an extension to BGP that allows for the BGP Flow-spec is an extension to BGP that supports the dissemination
dissemination of traffic flow specification rules. It leverages the of traffic flow specification rules. It uses the BGP Control Plane
BGP Control Plane to simplify the distribution of ACLs, new filter to simplify the distribution of ACLs and allows new filter rules to
rules can be injected to all BGP peers simultaneously without be injected to all BGP peers simultaneously without changing router
changing router configuration. The typical application of BGP Flow- configuration. A typical application of BGP Flow-spec is to automate
spec is to automate the distribution of traffic filter lists to the distribution of traffic filter lists to routers for DDOS
routers for DDOS mitigation. mitigation.
RFC5575 defines a new BGP Network Layer Reachability Information [RFC5575] defines a new BGP Network Layer Reachability Information
(NLRI) format used to distribute traffic flow specification rules. (NLRI) format used to distribute traffic flow specification rules.
NLRI (AFI=1, SAFI=133)is for IPv4 unicast filtering. NLRI (AFI=1, NLRI (AFI=1, SAFI=133) is for IPv4 unicast filtering. NLRI (AFI=1,
SAFI=134)is for BGP/MPLS VPN filtering. [IPv6-FlowSpec] and [Layer2- SAFI=134) is for BGP/MPLS VPN filtering. [IPv6-FlowSpec] and [Layer2-
FlowSpec] extend the flow-spec rules for IPv6 and layer 2 Ethernet FlowSpec] extend the flow-spec rules for IPv6 and layer 2 Ethernet
packets respectively. All these flow specifications match parts only packets respectively. All these previous flow specifications match
reflect single layer IP/Ethernet information like source/destination only single layer IP/Ethernet information like source/destination
MAC, source/destination IP prefix, protocol type, ports, and etc. MAC, source/destination IP prefix, protocol type, ports, and the
like.
In cloud computing era, multi-tenancy has become a core requirement In the cloud computing era, multi-tenancy has become a core
for data centers. Since NVO3 can satisfy multi-tenancy key requirement for data centers. Since NVO3 can satisfy multi-tenancy
requirements, this technology is being deployed in an increasing key requirements, this technology is being deployed in an increasing
number of cloud data center network. NVO3 is an overlay technology, number of cloud data center networks. NVO3 is an overlay technology,
VXLAN and NVGRE are two typical NVO3 encapsulations. GENEVE [draft- VXLAN [RFC7348] and NVGRE [RFC7367] are two typical NVO3
ietf-nvo3-geneve-00],GUE[draft-ietf-nvo3-gue-01] and GPE [draft- encapsulations. GENEVE [GENEVE], GUE [GUE] and GPE [GPE] are three
ietf-nvo3-vxlan-gpe-00] are three emerging NVO3 encapsulations in emerging NVO3 encapsulations. Because it is an overlay technology,
progress. flow specification matching on an inner header as well as the outer
header, as specifified below, is needed.
+--+ +--+
|CE| |CE|
+--+ +--+
| |
+----+ +----+
+----| PE |----+ +----| PE |----+
+---------+ | +----+ | +---------+ +---------+ | +----+ | +---------+
+----+ | +---+ +---+ | +----+ +----+ | +---+ +---+ | +----+
|NVE1|--| | | | | |--|NVE3| |NVE1|--| | | | | |--|NVE3|
+----+ | |GW1| |GW3| | +----+ +----+ | |GW1| |GW3| | +----+
| +---+ +---+ | | +---+ +---+ |
| NVO-1 | MPLS | NVO-2 | | NVO-1 | MPLS | NVO-2 |
| +---+ +---+ | | +---+ +---+ |
| | | | | | | | | | | |
+----+ | |GW2| |GW4| | +----+ +----+ | |GW2| |GW4| | +----+
|NVE2|--| +---+ +---+ |--|NVE4| |NVE2|--| +---+ +---+ |--|NVE4|
+----+ +---------+ | | +---------+ +----+ +----+ +---------+ | | +---------+ +----+
+--------------+ +--------------+
Figure 1 NVO3 data center interconnection
The MPLS L2/L3 VPN in the WAN network can be used for NVO3 based Figure 1. NVO3 Data Center Interconnection
data center network interconnection. When the DC and the WAN are
operated by the same administrative entity, the Service Provider can INTERNET-DRAFT NVO3 BGP Flow-Spec
decide to integrate the GW and WAN Edge PE functions in the same
router for obvious CAPEX and OPEX saving reasons. This is The MPLS L2/L3 VPN in the WAN network can be used for NVO3 based data
center network interconnection. When the DC and the WAN are operated
by the same administrative entity, the Service Provider can decide to
integrate the GW and WAN Edge PE functions in the same router for
obvious capital and operational cost saving reasons. This is
illustrated in Figure 1. There are two interconnection solutions as illustrated in Figure 1. There are two interconnection solutions as
follows: follows:
1. End to end NVO3 tunnel across different data centers. NVE1 1. End-to-end NVO3 tunnel across different data centers: NVE1 perform
perform NVO3 encapsulation for DCI interconnection with NVE3, the NVO3 encapsulation for DC interconnection with NVE3, the
destination VTEP IP is NVE3's IP. The GW doesn't perform NVO3 tunnel destination VTEP IP is NVE3's IP. The GW doesn't perform NVO3
termination. The DCI WAN is pure underlay network. tunnel termination. The DC interconnect WAN is pure an underlay
network.
2. Segmented NVO3 tunnels across different data centers. NVE1 2. Segmented NVO3 tunnels across different data centers: NVE1 doesn't
doesn't perform end to end NVO3 encapsulation to NVE3 for DCI perform end-to-end NVO3 encapsulation to NVE3 for DC
interconnection. The GW performs NVO3 tunnel encapsulation interconnection. The GW performs NVO3 tunnel encapsulation
termination, and then transmits the inner original traffic through termination, and then transmits the inner original traffic through
MPLS network to peer data center GW. The peer data center GW MPLS network to the peer data center GW. The peer data center GW
terminates MPLS encapsulation, and then performs NVO3 encapsulation terminates MPLS encapsulation, and then performs NVO3
to transmit the traffic to local NVE3. encapsulation to transmit the traffic to the local NVE3.
In the first solution, to differentiate bandwidth and QOS among In the first solution, to differentiate bandwidth and QOS among
different tenants or applications, different TE tunnels in the WAN different tenants or applications, different TE tunnels in the WAN
network will be used to carry the end to end NVO3 encapsulation network will be used to carry the end-to-end NVO3 encapsulation
traffic using VN ID, NVO3 outer header DSCP and etc as traffic traffic using VN ID, NVO3 outer header DSCP and etc as traffic
classification match part. BGP Flow-spec protocol can be used to set classification match part. BGP Flow-spec protocol can be used to set
the traffic classification on all GWs simultaneously. the traffic classification on all GWs simultaneously.
In the second solution, a centralized BGP speaker can be deployed In the second solution, a centralized BGP speaker can be deployed for
for DDOS mitigation in the WAN network. When the analyzer detects DDOS mitigation in the WAN network. When the analyzer detects
abnormal traffic, it will automatically generate Flow-spec rules and abnormal traffic, it will automatically generate Flow-spec rules and
distribute it to each GW through BGP Flow-spec protocol, the match distribute them to each GW through BGP Flow-spec protocol, the match
part should include inner or outer L2/L3 layer or NVO3 header. part should include matching on inner or outer L2/L3 layer or NVO3
headers.
In summary, the Flow specification match part on the GW/PE should In summary, the Flow specification match part on the GW/PE should
include inner layer 2 Ethernet header, inner layer 3 IP header, include inner layer 2 Ethernet header, inner layer 3 IP header, outer
outer layer 2 Ethernet header, outer layer 3 IP header, and/or NVO3 layer 2 Ethernet header, outer layer 3 IP header, and/or NVO3 header
header information. Because the current match part lacks layer information. Because the current flow-spec matching facilities lack a
indicator and NVO3 header information, so it can't be used directly layer indicator and NVO3 header information, they can't be used
for the traffic filtering based on NVO3 header or a specified layer directly for the traffic filtering based on NVO3 header or on a
header directly. This draft will propose a new subset of component specified layer header directly. This draft specifies a new subset of
types to support the NVO3 flow-spec application. component types to support the NVO3 flow-spec application.
2. The Flow Specification encoding for NVO3 INTERNET-DRAFT NVO3 BGP Flow-Spec
In default, the current flow-spec rules can only impose on the outer 1.1 Terminology
layer header of NVO3 encapsulation data packets. To make traffic
filtering based on NVO3 header and inner header of NVO3 packets, a
new component type acts as a delimiter is introduced. The delimiter
type is used to specify the boundary of the inner or outer layer
component types for NVO3 data packets. All the component types
defined in [RFC5575],[IPv6-FlowSpec],[Layer2-FlowSpec],and etc can
be used between two delimiters.
The NVO3 outer layer address normally belongs to public network, the The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"Flow Specification" NLRI only for the outer layer header doesn't "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
need to include Route Distinguisher field (8 bytes). If the outer document are to be interpreted as described in RFC 2119 [RFC2119].
layer address belongs to a VPN, the NLRI format for the outer header
should consist of a fixed-length Route Distinguisher field (8 bytes)
corresponding to the VPN, the RD is followed by the detail flow
specifications for the outer layer.
VN ID is the identification for each tenant network, the "Flow The reader is assumed to be familiar with BGP and NVO3 terminology.
Specification" NLRI for NVO3 header part should always include VN ID The following terms and acronyms are used in this document with the
field, Route Distinguisher field doesn't need to be included. meaning indicated:
The inner layer MAC/IP address always associates with a VN ID, the DC - Data Center
NLRI format for the inner header should consist of a fixed-length
VNID field (4 bytes), the VNID is followed by the detail flow DDOS - Distributed Denial of Service (Attack).
specifications for the inner layer. The NLRI length field shall
GW - gateway
VN - virtual network
WAN - wide area network
INTERNET-DRAFT NVO3 BGP Flow-Spec
2. NVO3 Flow Specification Encoding
The current Flow-spec rules can only recognize flows based on the
outer layer header of NVO3 encapsulation data packets. To enable
traffic filtering based on an NVO3 header and inner header of NVO3
packets, a new component type acting as a delimiter is introduced.
The delimiter type is used to specify the boundary between the inner
or outer layer component types for NVO3 data packets. All the
component types defined in [RFC5575], [IPv6-FlowSpec],
[Layer2-FlowSpec], and the like can be used between two delimiters.
Because the NVO3 outer layer address normally belongs to a public
network, the "Flow Specification" NLRI for the outer layer header
doesn't need to include a Route Distinguisher field (8 bytes). If the
outer layer address belongs to a VPN, the NLRI format for the outer
header should consist of a fixed-length Route Distinguisher field (8
bytes) corresponding to the VPN. This Route Distinguisher is followed
by the detail flow specifications for the outer layer.
The VN ID is the identification for each tenant network. The "Flow
Specification" NLRI for an NVO3 header part should always include VN
ID field but a Route Distinguisher field doesn't need to be included.
The inner layer MAC/IP address is always associated with a VN ID.
Thus the NLRI format for the inner header should consist of a fixed-
length VN ID field (4 bytes). The VN ID is followed by the detailed
flow specifications for the inner layer. The NLRI length field shall
include both the 4 bytes of the VN ID as well as the subsequent flow include both the 4 bytes of the VN ID as well as the subsequent flow
specification. In NVO3 terminating into VPN scenario, if multiple specification. In the NVO3 terminating into a VPN scenario, if
access VN ID maps to one VPN instance, one share VN ID can be multiple access VN IDs map to one VPN instance, one shared VN ID can
carried in the Flow-Spec rule to enforce the rule to entire VPN be carried in the Flow-Spec rule to enforce the rule to the entire
instance, the share VN ID and VPN correspondence should be VPN instance and the share VN ID and VPN correspondence should be
configured on each VPN PE beforehand, the function of the layer3 VN configured on each VPN PE beforehand. In this case, the function of
ID is same with Route Distinguisher to act as the identification of the layer3 VN ID is the same as a Route Distinguisher: it acts as the
VPN instance. identification of the VPN instance.
This document proposes the following extended specifications for This document specifies the following Flow-Spec Component Types for
NVO3 flow: use with NVO3 flows:
Type TBD1 - Delimiter type Type TBD1 - Delimiter type
Encoding: <type (1 octet), length (1 octet), Value>.
Encoding: <type (1 octet), length (1 octet), Value>. When this delimiter type is present, it indicates the component
types for the next layer of NVO3 header fields immediately
follow. At the same time, it indicates the end of the component
types belonging to the previous layer of header fields.
When the delimiter type is present, it indicates the component types The value field defines encapsulation type and is encoded as:
for the inner or outer layer of NVO3 packets will be followed
immediately. At the same time, it indicates the end of the component
types belonging to the former delimiter.
The value field defines encapsulation type and is encoded as: INTERNET-DRAFT NVO3 BGP Flow-Spec
0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| Encap Type | | Encap Type |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| I | O | Resv | | I | O | Resv |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
This document defines the following Encap types:
- VXLAN: Tunnel Type = 0 This document defines the following Encap types:
- NVGRE: Tunnel Type = 1 - VXLAN: Tunnel Type = 0
I: If I is set to one, it indicates the component types for the - NVGRE: Tunnel Type = 1
inner layer of NVO3 packets will be followed immediately.
O: If O is set to one, it indicates the component types for the I: If I is set to one, it indicates the component types for the
outer layer of NVO3 packets will be followed immediately. inner layer of NVO3 headers immediately follow.
For NVO3 header part, the following additional component types are O: If O is set to one, it indicates the component types for the
outer layer of NVO3 headers immediately follow.
For NVO3 header part, the following additional component types are
introduced. introduced.
Type TBD2 - VNID Type TBD2 - VN ID
Encoding: <type (1 octet), [op, value]+>. Encoding: <type (1 octet), [op, value]+>.
Defines a list of {operation, value} pairs used to match 24-bit VN Defines a list of {operation, value} pairs used to match 24-bit VN
ID which is used as tenant identification in NVO3 network. For NVGRE ID which is used as tenant identification in NVO3 network. For
encapsulation, the VNID is equivalent to VSID. Values are encoded as NVGRE encapsulation, the VN ID is equivalent to VSID. Values are
1- to 3-byte quantities. encoded as 1- to 3-byte quantities.
Type TBD3 - Flow ID Type TBD3 - Flow ID
Encoding: <type (1 octet), [op, value]+> Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match 8-bit Flow Defines a list of {operation, value} pairs used to match 8-bit
id fields which are only useful for NVGRE encapsulation. Values are Flow ID fields which are only useful for NVGRE encapsulation.
encoded as 1-byte quantity. Values are encoded as 1-byte quantity.
3. The Flow Specification Traffic Actions for NVO3 INTERNET-DRAFT NVO3 BGP Flow-Spec
The current traffic filtering actions can still be used for NVO3 3. NVO3 Flow Specification Traffic Actions
encapsulation traffic. For Traffic Marking, only the DSCP in outer
header can be modified. The current traffic filtering actions are used for NVO3 encapsulation
traffic. For Traffic Marking, only the DSCP in the outer header can
be modified.
4. Security Considerations 4. Security Considerations
No new security issues are introduced to the BGP protocol by this No new security issues are introduced to the BGP protocol by this
specification. specification.
5. IANA Considerations INTERNET-DRAFT NVO3 BGP Flow-Spec
IANA is requested to create and maintain a new registry entitled: 5. IANA Considerations
"Flow spec NVO3 Component Types": IANA is requested to assign three new Flow Spec Component Types as
follows:
Type TBD1 - Delimiter type Type Name Reference
---- -------------- ---------
TBD1 Delimiter type [this document]
TBD2 VN ID [this document]
TBD3 Flow ID [this document]
Type TBD2 - VNID INTERNET-DRAFT NVO3 BGP Flow-Spec
Type TBD3 - Flow ID Normative References
5.1. Normative References [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119,
March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[1] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC5575] - Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch,
J., and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<https://www.rfc-editor.org/info/rfc5575>.
Requirement Levels", BCP 14, RFC 2119, March 1997. [GENEVE] - J. Gross, T. Sridhar, etc, "Geneve: Generic Network
Virtualization Encapsulation", draft-ietf-nvo3-geneve, work in
progress.
[2] [GENEVE] J. Gross, T. Sridhar, etc, " Geneve: Generic Network [GUE] - T. Herbert, L. Yong, O. Zia, "Generic UDP Encapsulation",
Virtualization Encapsulation", draft-ietf-nvo3-geneve-00, May draft-ietf-nvo3-gue, work in progress.
2015.
[3] [GUE] T. Herbert, L. Yong, O. Zia, " Generic UDP INTERNET-DRAFT NVO3 BGP Flow-Spec
Encapsulation", draft-ietf-nvo3-gue-01, Jun 2015.
[4] [GPE] P. Quinn,etc, " Generic Protocol Extension for VXLAN", Informative References
draft-ietf-nvo3-vxlan-gpe-00, May 2015.
5.2. Informative References [RFC7348] - Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Networks",
RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-
editor.org/info/rfc7348>.
[1] [EVPN-Overlays] A. Sajassi,etc, " A Network Virtualization [RFC7367] - Garg, P., Ed., and Y. Wang, Ed., "NVGRE: Network
Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-01 , Virtualization Using Generic Routing Encapsulation", RFC 7637,
work in progress, February, 2014. DOI 10.17487/RFC7637, September 2015, <https://www.rfc-
editor.org/info/rfc7637>.
[2] [Inter-Overlays] J. Rabadan,etc, " Interconnect Solution for [EVPN-Overlays] - A. Sajassi,etc, "A Network Virtualization Overlay
EVPN Overlay networks", draft-ietf-bess-dci-evpn-overlay-01, Solution using EVPN", draft-ietf-bess-evpn-overlay, work in
work in progress, July, 2015. progress, February.
[3] [RFC7348] M. Mahalingam, etc, "Virtual eXtensible Local Area [Inter-Overlays] - J. Rabadan,etc, "Interconnect Solution for EVPN
Network (VXLAN): A Framework for Overlaying Virtualized Layer Overlay networks", draft-ietf-bess-dci-evpn-overlay, work in
2 Networks over Layer 3 Networks", RFC7348, August 2014. progress.
[4] [NVGRE] P. Garg, etc, "NVGRE: Network Virtualization using [IPv6-FlowSpec] - R. Raszuk, etc, "Dissemination of Flow
Generic Routing Encapsulation", draft-sridharan- Specification Rules for IPv6", draft-ietf-idr-flow-spec-v6,
virtualization-nvgre-08, April 13, 2015. work in progress.
[5] [IPv6-FlowSpec] R. Raszuk, etc, " Dissemination of Flow [Layer2-FlowSpec] - W. Hao, etc, "Dissemination of Flow Specification
Specification Rules for IPv6", draft-ietf-idr-flow-spec-v6-06, Rules for L2 VPN", draft-ietf-idr-flowspec-l2vpn, work in
November 2014. progress.
[6] [Layer2-FlowSpec] W. Hao, etc, "Dissemination of Flow [GPE] - P. Quinn,etc, "Generic Protocol Extension for VXLAN", draft-
Specification Rules for L2 VPN", draft-ietf-idr-flowspec- ietf-nvo3-vxlan-gpe, work in progress.
l2vpn-02, August 2015.
[7] [RFC5575] P. Marques, N. Sheth, R. Raszuk, B. Greene, J.Mauch, INTERNET-DRAFT NVO3 BGP Flow-Spec
D. McPherson, "Dissemination of Flow Specification Rules", RFC
5575, August 2009.
6. Acknowledgments Acknowledgments
The authors wish to acknowledge the important contributions of Jeff The authors wish to acknowledge the important contributions of Jeff
Haas, Susan Hares, Qiandeng Liang, Nan Wu, Yizhou Li, Lucy Yong. Haas, Susan Hares, Qiandeng Liang, Nan Wu, Yizhou Li, and Lucy Yong.
Authors' Addresses Authors' Addresses
Weiguo Hao Donald Eastlake
Huawei Technologies Huawei Technologies
101 Software Avenue, 155 Beaver Street
Nanjing 210012 Milford, MA 01757 USA
China
Email: haoweiguo@huawei.com
Shunwan Zhuang Tel: +1-508-333-2270
Huawei Technologies Email: d3e3e3@gmail.com
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Zhenbin Li Weiguo Hao
Huawei Technologies Huawei Technologies
Huawei Bld., No.156 Beiqing Rd. 101 Software Avenue,
Beijing 100095 Nanjing 210012 China
China
Email: lizhenbin@huawei.com
Rong Gu Email: haoweiguo@huawei.com
China Mobile
gurong_cmcc@outlook.com Shunwan Zhuang
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095 China
Email: zhuangshunwan@huawei.com
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095 China
Email: lizhenbin@huawei.com
Rong Gu
China Mobile
Email: gurong_cmcc@outlook.com
INTERNET-DRAFT NVO3 BGP Flow-Spec
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2017 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.
 End of changes. 77 change blocks. 
214 lines changed or deleted 254 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/