--- 1/draft-ietf-idr-flowspec-l2vpn-02.txt 2015-11-15 23:15:03.586602263 -0800 +++ 2/draft-ietf-idr-flowspec-l2vpn-03.txt 2015-11-15 23:15:03.614602950 -0800 @@ -1,23 +1,23 @@ IDR W. Hao Q. Liang Internet Draft Huawei Intended status: Standards Track Jim Uttaro AT&T S. Litkowski Orange Business Service S. Zhuang Huawei -Expires: February 2016 August 12, 2015 +Expires: May 2016 November 16, 2015 Dissemination of Flow Specification Rules for L2 VPN - draft-ietf-idr-flowspec-l2vpn-02.txt + draft-ietf-idr-flowspec-l2vpn-03.txt Abstract This document defines BGP flow-spec extension for Ethernet traffic filtering in L2 VPN network. SAFI=134 in [RFC5575] is redefined for dissemination traffic filtering information in an L2VPN environment. A new subset of component types and extended community also are defined. Status of this Memo @@ -54,26 +54,27 @@ 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 2. Layer 2 Flow Specification encoding in BGP................... 3 3. Ethernet Flow Specification encoding in BGP.................. 4 - 4. Ethernet Flow Specification Traffic Actions.................. 6 - 5. Security Considerations...................................... 9 - 6. IANA Considerations ......................................... 9 - 6.1. Normative References................................... 10 - 6.2. Informative References................................. 11 - 7. Acknowledgments ............................................ 11 + 3.1. Order of Traffic Filtering Rules........................ 6 + 4. Ethernet Flow Specification Traffic Actions.................. 7 + 5. Security Considerations..................................... 10 + 6. IANA Considerations ........................................ 10 + 6.1. Normative References................................... 12 + 6.2. Informative References................................. 12 + 7. Acknowledgments ............................................ 12 1. Introduction BGP Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. It leverages the BGP Control Plane to simplify the distribution of ACLs, 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, access control, etc. @@ -97,24 +98,24 @@ it is imported. For non-IP Ethernet traffic filtering, Layer 2 related information like source/destination MAC and VLAN should be considered. But the flow specification match criteria defined in RFC5575 only include layer 3 and layer 4 IP information, layer 2 Ethernet information haven't been included. There are different kinds of L2VPN networks like EVPN [EVPN], BGP VPLS [RFC4761], LDP VPLS [RFC4762] and border gateway protocol (BGP) auto discovery [RFC 6074]. Because the flow-spec feature relies on BGP protocol to distribute traffic filtering rules, so it can only - be incrementally deployed in those L2VPN networks where BGP is used - for auto discovery and/or signaling purposes such as BGP-based VPLS - [4761], EVPN and LDP-based VPLS [4762] with BGP auto-discovery - [6074]. + be incrementally deployed in those L2VPN networks where BGP has + already been used for auto discovery and/or signaling purposes such + as BGP-based VPLS [4761], EVPN and LDP-based VPLS [4762] with BGP + auto-discovery [6074]. This draft proposes a new subset of component types and extended community to support L2VPN flow-spec application. The flow-spec rules can be enforced on all border routers or on some interface 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 The [RFC5575] defines SAFI 133 and SAFI 134 for ''dissemination of @@ -145,52 +146,50 @@ Flow specification rules received via this NLRI apply only to traffic that belongs to the VPN instance(s) in which it is imported. Flow rules are accepted by default, when received from remote PE routers. Besides the component types defined in [RFC5575] and [draft-ietf- idr-flow-spec-v6-06], this document proposes the following additional component types for L2VPN Ethernet traffic filtering: - Type 14 - Source MAC + Type 14 - Ethernet Type Encoding: - Defines a list of {operation(op), value} pairs used to match source - MAC. Values are encoded as 6-byte quantities. The operation field is - encoded as ''Numeric operator'' defined in [RFC5575]. - - Type 15 - Destination MAC + Defines a list of {operation, value} pairs used to match two-octet + field. Values are encoded as 2-byte quantities. Ethernet II framing + defines the two-octet Ethernet Type field in an Ethernet frame, + preceded by destination and source MAC addresses, that identifies an + upper layer protocol encapsulating the frame data. - Encoding: + Type 15 - Source MAC - Defines a list of {operation, value} pairs used to match destination - MAC. Values are encoded as 6-byte quantities. + Encoding: - Type 16 - Ethernet Type + Defines the source MAC Address to match. - Encoding: + Type 16 - Destination MAC - Defines a list of {operation, value} pairs used to match two-octet - field. Values are encoded as 2-byte quantities. + Encoding: - Ethernet II framing defines the two-octet EtherType field in an - Ethernet frame, preceded by destination and source MAC addresses, - that identifies an upper layer protocol encapsulating the frame data. + Defines the destination MAC Address to match. Type 17 - DSAP(Destination Service Access Point) in LLC Encoding: + Defines a list of {operation, value} pairs used to match 1-octet DSAP in the 802.2 LLC(Logical Link Control Header). Values are - encoded as 1-byte quantities. + encoded as 1-byte quantities. The operation field is encoded as + 'Numeric operator' defined in [RFC5575]. Type 18 - SSAP(Source Service Access Point) in LLC Encoding: Defines a list of {operation, value} pairs used to match 1-octet SSAP in the 802.2 LLC. Values are encoded as 1-byte quantities. Type 19 - Control field in LLC @@ -245,20 +243,60 @@ Encoding: 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) 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 significant bits contain the VLAN COS value. In single VLAN case, the component type MUST not be used. +3.1. Order of Traffic Filtering Rules + + The original definition for the order of traffic filtering rules can + be reused with new consideration for the MAC Address offset. As long + as the offsets are equal, the comparison is the same, retaining + longest-prefix-match semantics. If the offsets are not equal, the + lowest offset has precedence, as this flow matches the most + significant bit. + + Pseudocode: + flow_rule_L2_cmp (a, b) + { + comp1 = next_component(a); + comp2 = next_component(b); + while (comp1 || comp2) { + // component_type returns infinity on end-of-list + if (component_type(comp1) < component_type(comp2)) { + return A_HAS_PRECEDENCE; + } + if (component_type(comp1) > component_type(comp2)) { + return B_HAS_PRECEDENCE; + } + + if (component_type(comp1) == MAC_DESTINATION || MAC_SOURCE) { + common = MIN(MAC Address length (comp1), + MAC Address length (comp2)); + cmp = MAC Address compare(comp1, comp2, common); + // not equal, lowest value has precedence + // equal, longest match has precedence + } else { + common = + MIN(component_length(comp1), component_length(comp2)); + cmp = memcmp(data(comp1), data(comp2), common); + // not equal, lowest value has precedence + // equal, longest string has precedence + } + } + return EQUAL; + } + 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 | +--------+--------------------+--------------------------+ @@ -276,96 +314,83 @@ flow to extend [RFC5575]: +--------+------------------------+--------------------------+ | type | extended community | encoding | +--------+------------------------+--------------------------+ | TBD1 | VLAN-action | bitmask | | TBD2 | TPID-action | bitmask | +--------+------------------------+--------------------------+ VLAN-action: The VLAN-action extended community consists of 6 bytes - 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 - to indicate the action type. The two VLAN ID/COS value are carried - in COS1/VLAN ID1 and COS2/VLAN ID2 field respectively. + which include the fields of action Flags, two VLAN IDs and the + associating COS value. The action Flags fields are further divided + into two parts which corresponds to the first action and the second + action respectively, bit 0 to bit 7 belong to the first action part + while bit 8 to bit 15 belong to the second part. The bits of PO, PU, + SW, RI and RO in each part represent Pop, Push, Swap, Rewrite inner + VLAN and Rewrite outer VLAN respectively. Through this method, more + complicated actions also can be represented in a single VLAN-action + extend community, such as SwapPop, PushSwap, etc. For example, + SwapPop action is the concatenation of two actions, the first action + is Swap and the second action is Pop. - 0 15 + 0 7 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - |PO|PU|P2|SW|RI|RO|CI|CO| Resv | + |PO1|PU1|SW1|RI1|RO1|...|PO2|PU2|SW2|RI2|RO2|...| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | COS1 |R | VLAN ID1 | + | VLAN ID1 |COS1 |R1| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | COS2 |R | VLAN ID2 | + | VLAN ID2 |COS2 |R2| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - PO: Pop action. If the PO flag is one it indicates the outmost VLAN - should be removed. - - PU: Push action. If PU is one it indicates VLAN ID1 will be added. - 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. + PO1: Pop action. If the PO1 flag is one it indicates the outmost + VLAN should be removed. - P2: Push action 2. If P2 is one it indicates VLAN ID2 will be added. - If PU is zero and P2 is one, the format is invalid and no VLAN Push - action should be taken. + PU1: Push action. If PU1 is one it indicates VLAN ID1 will be added, + the associated COS is COS1. - SW: Swap action. If the SW flag is one it indicates the outer VLAN + SW1: Swap action. If the SW1 flag is one it indicates the outer VLAN and inner VLAN should be swapped. - RI: Rewrite inner VLAN action. If the RI flag is one it indicates - the inner VLAN should be replaced by a new VLAN, the new VLAN is - VLAN ID1. - - RO: Rewrite outer VLAN action. If the RO flag is one it indicates - the outer VLAN should be replaced by a new VLAN, the new VLAN is - VLAN ID2. - - CI: Mapping inner COS action. If the CI flag is one it indicates the - 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. + PO2: Pop action. If the PO2 flag is one it indicates the outmost + VLAN should be removed. - COS1: 3 bits. COS value. + PU2: Push action. If PU2 is one it indicates VLAN ID2 will be added, + the associated COS is COS2. - COS2: 3 bits. COS value. + SW2: Swap action. If the SW2 flag is one it indicates the outer VLAN + and inner VLAN should be swapped. - VLAN ID1: 12 bits. VLAN ID value. + RI1 and RI2: Rewrite inner VLAN action. If the RI flag is one it + indicates the inner VLAN should be replaced by a new VLAN, the new + VLAN is VLAN ID1, the associated COS is COS1. If the VLAN ID1 is 0, + the action is to only modify the COS value of inner VLAN. - VLAN ID2: 12 bits. VLAN ID value. + RO1 and RO2: Rewrite outer VLAN action. If the RO flag is one it + indicates the outer VLAN should be replaced by a new VLAN, the new + VLAN is VLAN ID2, the associated COS is COS2. If the VLAN ID2 is 0, + the action is to only modify the COS value of outer VLAN. - R: Reserved for future use. + R1 and R2: 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: + Giving an example, if the action of PUSH Inner VLAN 10 with COS + value 5 and Outer VLAN 20 with COS value 6 is needed, the format of + the VLAN-action extended community is as follows: - 0 15 + 0 7 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - |0 |1 |1 |0 |0 |0 |0 |0 | 0 | + |0 |1 |0 |0 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 |0 |0 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | 0 |0 | 10 | + | 10 |1 |0 |1 |0 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | 0 |0 | 20 | + | 20 |1 |1 |0 |0 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 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 which includes the fields of action Flags, TPID1 and TPID2. 0 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |TI|TO| Resv | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TP ID1 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ @@ -410,23 +435,23 @@ | 4 |RFC5575 | Port | | 5 |RFC5575 | Destination port | | 6 |RFC5575 | Source port | | 7 |RFC5575 | ICMP type | | 8 |RFC5575 | ICMP code | | 9 |RFC5575 | TCP flags | | 10 |RFC5575 | Packet length | | 11 |RFC5575 | DSCP | | 12 |RFC5575 | Fragment | | 13 |draft-ietf-idr-flow-spec-v6-06 | Flow Label | - | 14 |This draft | Source MAC | - | 15 |This draft | Destination MAC | - | 16 |This draft | Ethernet Type | + | 14 |This draft | Ethernet Type | + | 15 |This draft | Source MAC | + | 16 |This draft | Destination MAC | | 17 |This draft | DSAP in LLC | | 18 |This draft | SSAP in LLC | | 19 |This draft | Control field in LLC | | 20 |This draft | SNAP | | 21 |This draft | VLAN ID | | 22 |This draft | VLAN COS | | 23 |This draft | Inner VLAN ID | | 24 |This draft | Inner VLAN COS | +--------+-------------------------------+--------------------------+ IANA is requested to update the reference for the following @@ -466,21 +492,21 @@ [1] [EVPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft- ietf-l2vpn-evpn-07.txt, work in progress, May, 2014. [2] [IEEE 802.1p] Javin, et.al. "IEEE 802.1p: LAN Layer 2 QoS/CoS Protocol for Traffic Prioritization", 2012-02-15 7. Acknowledgments The authors wish to acknowledge the important contributions of - Hannes Gredler, Xiaohu Xu and Lucy Yong. + Hannes Gredler, Xiaohu Xu, Zhenbin Li and Lucy Yong. Authors' Addresses Weiguo Hao Huawei Technologies 101 Software Avenue, Nanjing 210012 China Email: haoweiguo@huawei.com