draft-ietf-idr-flowspec-l2vpn-01.txt   draft-ietf-idr-flowspec-l2vpn-02.txt 
IDR W. Hao IDR W. Hao
Q. Liang Q. Liang
Internet Draft Huawei Technologies Ltd. Internet Draft Huawei
Intended status: Standards Track Jim Uttaro Intended status: Standards Track Jim Uttaro
AT&T AT&T
S. Litkowski S. Litkowski
Orange Business Service Orange Business Service
S. Zhuang S. Zhuang
Huawei Technologies Ltd. Huawei
Expires: November 2015 May 9, 2015 Expires: February 2016 August 12, 2015
Dissemination of Flow Specification Rules for L2 VPN Dissemination of Flow Specification Rules for L2 VPN
draft-ietf-idr-flowspec-l2vpn-01.txt draft-ietf-idr-flowspec-l2vpn-02.txt
Abstract Abstract
This document defines BGP flow-spec extension for Ethernet traffic This document defines BGP flow-spec extension for Ethernet traffic
filtering in L2 VPN network. SAFI=134 in [RFC5575] is redefined for filtering in L2 VPN network. SAFI=134 in [RFC5575] is redefined for
dissemination traffic filtering information in an L2VPN environment. dissemination traffic filtering information in an L2VPN environment.
A new subset of component types and extended community also are A new subset of component types and extended community also are
defined. defined.
Status of this Memo Status of this Memo
skipping to change at page 2, line 21 skipping to change at page 2, line 21
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ................................................ 2 1. Introduction ................................................ 2
2. Layer 2 Flow Specification encoding in BGP................... 3 2. Layer 2 Flow Specification encoding in BGP................... 3
3. Ethernet Flow Specification encoding in BGP.................. 4 3. Ethernet Flow Specification encoding in BGP.................. 4
4. Ethernet Flow Specification Traffic Actions.................. 6 4. Ethernet Flow Specification Traffic Actions.................. 6
5. Security Considerations...................................... 8 5. Security Considerations...................................... 9
6. IANA Considerations ......................................... 8 6. IANA Considerations ......................................... 9
6.1. Normative References................................... 10 6.1. Normative References................................... 10
6.2. Informative References................................. 10 6.2. Informative References................................. 11
7. Acknowledgments ............................................ 10 7. Acknowledgments ............................................ 11
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 allows for the
dissemination of traffic flow specification rules. It leverages the dissemination of traffic flow specification rules. It leverages the
BGP Control Plane to simplify the distribution of ACLs, new filter BGP Control Plane to simplify the distribution of ACLs, new filter
rules can be injected to all BGP peers simultaneously without rules can be injected to all BGP peers simultaneously without
changing router configuration. The typical application of BGP Flow- changing router configuration. The typical application of BGP Flow-
spec is to automate the distribution of traffic filter lists to spec is to automate the distribution of traffic filter lists to
routers for DDOS mitigation. routers for DDOS mitigation, access control, etc.
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. The Flow specification match SAFI=134)is for BGP/MPLS VPN filtering. The Flow specification match
part only includes L3/L4 information like source/destination prefix, part only includes L3/L4 information like source/destination prefix,
protocol, ports, and etc, so traffic flows can only be selectively protocol, ports, and etc, so traffic flows can only be selectively
filtered based on L3/L4 information. filtered based on L3/L4 information.
Layer 2 Virtual Private Networks L2VPNs have already been deployed Layer 2 Virtual Private Networks L2VPNs have already been deployed
in an increasing number of networks today. In L2VPN network, we also in an increasing number of networks today. In L2VPN network, we also
have requirement to deploy BGP Flow-spec to mitigate DDoS attack have requirement to deploy BGP Flow-spec to mitigate DDoS attack
traffic. Within L2VPN network, both IP and non-IP Ethernet traffic traffic. Within L2VPN network, both IP and non-IP Ethernet traffic
maybe exist. For IP traffic filtering, the Flow specification rules maybe exist. For IP traffic filtering, the Flow specification rules
skipping to change at page 3, line 24 skipping to change at page 3, line 24
There are different kinds of L2VPN networks like EVPN [EVPN], BGP There are different kinds of L2VPN networks like EVPN [EVPN], BGP
VPLS [RFC4761], LDP VPLS [RFC4762] and border gateway protocol (BGP) VPLS [RFC4761], LDP VPLS [RFC4762] and border gateway protocol (BGP)
auto discovery [RFC 6074]. Because the flow-spec feature relies on auto discovery [RFC 6074]. Because the flow-spec feature relies on
BGP protocol to distribute traffic filtering rules, so it can only BGP protocol to distribute traffic filtering rules, so it can only
be incrementally deployed in those L2VPN networks where BGP is used be incrementally deployed in those L2VPN networks where BGP is used
for auto discovery and/or signaling purposes such as BGP-based VPLS for auto discovery and/or signaling purposes such as BGP-based VPLS
[4761], EVPN and LDP-based VPLS [4762] with BGP auto-discovery [4761], EVPN and LDP-based VPLS [4762] with BGP auto-discovery
[6074]. [6074].
This draft proposes a new subset of component types and extended This draft proposes a new subset of component types and extended
community to support L2VPN flow-spec application. SAFI=134 in community to support L2VPN flow-spec application. The flow-spec
[RFC5575] is redefined for dissemination traffic filtering rules can be enforced on all border routers or on some interface
information in an L2VPN environment. sets of the border routers. SAFI=134 in [RFC5575] is redefined for
dissemination traffic filtering information in an L2VPN environment.
2. Layer 2 Flow Specification encoding in BGP 2. Layer 2 Flow Specification encoding in BGP
The [RFC5575] defines SAFI 133 and SAFI 134 for ''dissemination of The [RFC5575] defines SAFI 133 and SAFI 134 for ''dissemination of
IPv4 flow specification rules'' and ''dissemination of VPNv4 flow IPv4 flow specification rules'' and ''dissemination of VPNv4 flow
specification rules'' respectively. [draft-ietf-idr-flow-spec-v6-06] specification rules'' respectively. [draft-ietf-idr-flow-spec-v6-06]
redefines the [RFC5575] SAFIs in order to make them applicable to redefines the [RFC5575] SAFIs in order to make them applicable to
both IPv4 and IPv6 applications. This document will further redefine both IPv4 and IPv6 applications. This document will further redefine
the SAFI 134 in order to make them applicable to L2VPN applications. the SAFI 134 in order to make them applicable to L2VPN applications.
skipping to change at page 6, line 32 skipping to change at page 6, line 32
Defines a list of {operation, value} pairs used to match 3-bit inner Defines a list of {operation, value} pairs used to match 3-bit inner
VLAN COS fields [802.1p] using for virtual local-area network (VLAN) VLAN COS fields [802.1p] using for virtual local-area network (VLAN)
stacking or Q in Q case. Values are encoded using a single byte, stacking or Q in Q case. Values are encoded using a single byte,
where the five most significant bits are zero and the three least where the five most significant bits are zero and the three least
significant bits contain the VLAN COS value. significant bits contain the VLAN COS value.
In single VLAN case, the component type MUST not be used. In single VLAN case, the component type MUST not be used.
4. Ethernet Flow Specification Traffic Actions 4. Ethernet Flow Specification Traffic Actions
The default action for a layer 2 traffic filtering flow
specification is to accept traffic that matches that particular rule.
The following extended community values per RFC5575 can be used to
specify particular actions in L2VPN network:
+--------+--------------------+--------------------------+ +--------+--------------------+--------------------------+
| type | extended community | encoding | | type | extended community | encoding |
+--------+--------------------+--------------------------+ +--------+--------------------+--------------------------+
| 0x8006 | traffic-rate | 2-byte as#, 4-byte float | | 0x8006 | traffic-rate | 2-byte as#, 4-byte float |
| 0x8007 | traffic-action | bitmask | | 0x8007 | traffic-action | bitmask |
| 0x8008 | redirect | 6-byte Route Target | | 0x8008 | redirect | 6-byte Route Target |
| 0x8009 | traffic-marking | DSCP value | | 0x8009 | traffic-marking | DSCP value |
+--------+--------------------+--------------------------+ +--------+--------------------+--------------------------+
Besides to support the above extended communities per RFC5575, this Redirect: The action should be redefined to allow the traffic to be
document also proposes the following BGP extended communities redirected to a MAC or IP VRF routing instance that lists the
specifications for Ethernet flow to extend [RFC5575]: specified route-target in its import policy.
Besides the above extended communities, this document also proposes
the following BGP extended communities specifications for Ethernet
flow to extend [RFC5575]:
+--------+------------------------+--------------------------+ +--------+------------------------+--------------------------+
| type | extended community | encoding | | type | extended community | encoding |
+--------+------------------------+--------------------------+ +--------+------------------------+--------------------------+
| 0x800A | VLAN-action | bitmask | | TBD1 | VLAN-action | bitmask |
| 0x800B | TPID-action | bitmask | | TBD2 | TPID-action | bitmask |
+--------+------------------------+--------------------------+ +--------+------------------------+--------------------------+
VLAN-action: The VLAN-action extended community consists of 6 bytes VLAN-action: The VLAN-action extended community consists of 6 bytes
which include the fields of action Flags, and two VLAN ID/COS value. which include the fields of action Flags, and two VLAN ID/COS value.
The action Flags field includes PO, PU, SW, RI, RO, CI and CO Flag The action Flags field includes PO, PU, SW, RI, RO, CI and CO Flag
to indicate the action type. The two VLAN ID/COS value are carried to indicate the action type. The two VLAN ID/COS value are carried
in COS1/VLAN ID1 and COS2/VLAN ID2 field respectively. in COS1/VLAN ID1 and COS2/VLAN ID2 field respectively.
0 15 0 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|PO|PU|SW|RI|RO|CI|CO| Resv | |PO|PU|P2|SW|RI|RO|CI|CO| Resv |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| COS1 |R | VLAN ID1 | | COS1 |R | VLAN ID1 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| COS2 |R | VLAN ID2 | | COS2 |R | VLAN ID2 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
PO: Pop action. It indicates the outmost VLAN should be removed. PO: Pop action. If the PO flag is one it indicates the outmost VLAN
should be removed.
PU: Push action. It indicates a new VLAN should be added as outmost PU: Push action. If PU is one it indicates VLAN ID1 will be added.
VLAN, the new VLAN is VLAN ID1. If PU is one and P2 is set to zero, VLAN ID1 is the outmost VLAN. If
PU and P2 are both set to one, VLAN ID1 will be the inner VLAN and
VLAN ID2 will be the outer VLAN.
SW: Swap action. It indicates the outer VLAN and inner VLAN should P2: Push action 2. If P2 is one it indicates VLAN ID2 will be added.
be swapped. If PU is zero and P2 is one, the format is invalid and no VLAN Push
action should be taken.
RI: Rewrite inner VLAN action. It indicates the inner VLAN should be SW: Swap action. If the SW flag is one it indicates the outer VLAN
replaced by a new VLAN, the new VLAN is VLAN ID1. and inner VLAN should be swapped.
RO: Rewrite outer VLAN action. It indicates the outer VLAN should be RI: Rewrite inner VLAN action. If the RI flag is one it indicates
replaced by a new VLAN, the new VLAN is VLAN ID2. the inner VLAN should be replaced by a new VLAN, the new VLAN is
VLAN ID1.
CI: Mapping inner COS action. It indicates the inner COS should be RO: Rewrite outer VLAN action. If the RO flag is one it indicates
replaced by a new COS, the new COS is COS1. the outer VLAN should be replaced by a new VLAN, the new VLAN is
VLAN ID2.
CO: Mapping outer COS action. It indicates the outer COS should be CI: Mapping inner COS action. If the CI flag is one it indicates the
replaced by a new COS, the new COS is COS2. inner COS should be replaced by a new COS, the new COS is COS1.
CO: Mapping outer COS action. If the CO flag is one it indicates the
outer COS should be replaced by a new COS, the new COS is COS2.
Resv: Reserved for future use. Resv: Reserved for future use.
COS1: 3 bits. COS value. COS1: 3 bits. COS value.
COS2: 3 bits. COS value. COS2: 3 bits. COS value.
VLAN ID1: 12 bits. VLAN ID value. VLAN ID1: 12 bits. VLAN ID value.
VLAN ID2: 12 bits. VLAN ID value. VLAN ID2: 12 bits. VLAN ID value.
R: Reserved for future use. R: Reserved for future use.
For example, if PUSH Inner VLAN 10 and Outer VLAN 20 action is
needed, the format of the VLAN-action extended community is as
follows:
0 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|0 |1 |1 |0 |0 |0 |0 |0 | 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 0 |0 | 10 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 0 |0 | 20 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
In some cases, more complicated actions are needed, such as SwapPop,
PushSwap, etc. These actions can't be represented by single one
VLAN-action extended community and should be represented by the
catenation of two VLAN-actions which are carried in two separate
VLAN-action extended communities. The arrival order of the VLAN-
actions decides the action order. For example, SwapPop action can be
represented by the catenation of Swap action 1 and Pop action 2,
PushSwap action can be represented by the catenation of Push action
1 and Swap action 2.
TPID-action: The TPID-action extended community consists of 6 bytes TPID-action: The TPID-action extended community consists of 6 bytes
which include the fields of action Flags, TPID1 and TPID2. which includes the fields of action Flags, TPID1 and TPID2.
0 15 0 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|TI|TO| Resv | |TI|TO| Resv |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TP ID1 | | TP ID1 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TP ID2 | | TP ID2 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
TI: Mapping inner TP ID action. It indicates the inner TP ID should TI: Mapping inner TP ID action. If the TI flag is one it indicates
be replaced by a new TP ID, the new TP ID is TP ID1. the inner TP ID should be replaced by a new TP ID, the new TP ID is
TP ID1.
TO: Mapping outer TP ID action. It indicates the outer TP ID should TO: Mapping outer TP ID action. If the TO flag is one it indicates
be replaced by a new TP ID, the new TP ID is TP ID2. the outer TP ID should be replaced by a new TP ID, the new TP ID is
TP ID2.
Resv: Reserved for future use. Resv: Reserved for future use.
In some cases, some more complicated actions are needed, such as
SwapPop, PushSwap, etc. These actions can be represented using two
catenated VLAN-actions which are carried in two VLAN-action extended
communities. For example, Swap and Pop action can be represented by
catenation of Swap action 1 and Pop action 2.
5. Security Considerations 5. 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.
6. IANA Considerations 6. IANA Considerations
IANA is requested to rename currently defined SAFI 134 per [RFC5575] IANA is requested to rename currently defined SAFI 134 per [RFC5575]
to read: to read:
skipping to change at page 11, line 21 skipping to change at page 12, line 21
China China
Email: haoweiguo@huawei.com Email: haoweiguo@huawei.com
Qiandeng Liang Qiandeng Liang
Huawei Technologies Huawei Technologies
101 Software Avenue, 101 Software Avenue,
Nanjing 210012 Nanjing 210012
China China
Email: liangqiandeng@huawei.com Email: liangqiandeng@huawei.com
James Uttaro
AT&T
Email: uttaro@att.com
Stephane Litkowski
Orange
Email: stephane.litkowski@orange.com
Shunwan Zhuang Shunwan Zhuang
Huawei Technologies Huawei Technologies
Huawei Bld., No.156 Beiqing Rd. Huawei Bld., No.156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: zhuangshunwan@huawei.com Email: zhuangshunwan@huawei.com
James Uttaro
AT&T
EMail: uttaro@att.com
Stephane Litkowski
Orange
stephane.litkowski@orange.com
 End of changes. 26 change blocks. 
43 lines changed or deleted 88 lines changed or added

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