draft-ietf-pce-pcep-flowspec-02.txt   draft-ietf-pce-pcep-flowspec-03.txt 
Network Working Group D. Dhody, Ed. Network Working Group D. Dhody
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Standards Track A. Farrel, Ed. Intended status: Standards Track A. Farrel
Expires: April 19, 2019 Juniper Networks Expires: August 18, 2019 Old Dog Consulting
Z. Li Z. Li
Huawei Technologies Huawei Technologies
October 16, 2018 February 14, 2019
PCEP Extension for Flow Specification PCEP Extension for Flow Specification
draft-ietf-pce-pcep-flowspec-02 draft-ietf-pce-pcep-flowspec-03
Abstract Abstract
The Path Computation Element (PCE) is a functional component capable The Path Computation Element (PCE) is a functional component capable
of selecting the paths through a traffic engineered network. These of selecting the paths through a traffic engineered network. These
paths may be supplied in response to requests for computation, or may paths may be supplied in response to requests for computation, or may
be unsolicited instructions issued by the PCE to network elements. be unsolicited instructions issued by the PCE to network elements.
Both approaches use the PCE Communication Protocol (PCEP) to convey Both approaches use the PCE Communication Protocol (PCEP) to convey
the details of the computed path. the details of the computed path.
Traffic flows may be categorized and described using "Flow Traffic flows may be categorized and described using "Flow
Specifications". RFC 5575 defines the Flow Specification and Specifications". RFC 5575 defines the Flow Specification and
describes how it may be distributed in BGP to allow specific traffic describes how Flow Specification Components are used to describe
flows to be associated with routes. traffic flows. RFC 5575 also defines how Flow Specifications may be
distributed in BGP to allow specific traffic flows to be associated
with routes.
This document specifies a set of extensions to PCEP to support This document specifies a set of extensions to PCEP to support
dissemination of Flow Specifications. This allows a PCE to indicate dissemination of Flow Specifications. This allows a PCE to indicate
what traffic should be placed on each path that it is aware of. what traffic should be placed on each path that it is aware of.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 19, 2019. This Internet-Draft will expire on August 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Procedures for PCE Use of Flow Specifications . . . . . . . . 4 3. Procedures for PCE Use of Flow Specifications . . . . . . . . 5
3.1. Capability Advertisement . . . . . . . . . . . . . . . . 5 3.1. Capability Advertisement . . . . . . . . . . . . . . . . 5
3.1.1. PCEP OPEN Message . . . . . . . . . . . . . . . . . . 5 3.1.1. PCEP OPEN Message . . . . . . . . . . . . . . . . . . 5
3.1.2. IGP PCE Capabilities Advertisement . . . . . . . . . 5 3.1.2. IGP PCE Capabilities Advertisement . . . . . . . . . 6
3.2. Dissemination Procedures . . . . . . . . . . . . . . . . 6 3.2. Dissemination Procedures . . . . . . . . . . . . . . . . 6
3.3. Flow Specification Synchronization . . . . . . . . . . . 7 3.3. Flow Specification Synchronization . . . . . . . . . . . 7
4. PCE FlowSpec Capability TLV . . . . . . . . . . . . . . . . . 7 4. PCE FlowSpec Capability TLV . . . . . . . . . . . . . . . . . 8
5. PCEP FLOWSPEC Object . . . . . . . . . . . . . . . . . . . . 8 5. PCEP FLOWSPEC Object . . . . . . . . . . . . . . . . . . . . 8
6. Flow Filter TLV . . . . . . . . . . . . . . . . . . . . . . . 10 6. Flow Filter TLV . . . . . . . . . . . . . . . . . . . . . . . 10
7. Flow Specification TLVs . . . . . . . . . . . . . . . . . . . 10 7. Flow Specification TLVs . . . . . . . . . . . . . . . . . . . 10
8. Detailed Procedures . . . . . . . . . . . . . . . . . . . . . 13 8. Detailed Procedures . . . . . . . . . . . . . . . . . . . . . 14
8.1. Default Behavior and Backward Compatibility . . . . . . . 13 8.1. Default Behavior and Backward Compatibility . . . . . . . 14
8.2. Composite Flow Specifications . . . . . . . . . . . . . . 13 8.2. Composite Flow Specifications . . . . . . . . . . . . . . 14
8.3. Modifying Flow Specifications . . . . . . . . . . . . . . 14 8.3. Modifying Flow Specifications . . . . . . . . . . . . . . 14
8.4. Multiple Flow Specifications . . . . . . . . . . . . . . 14 8.4. Multiple Flow Specifications . . . . . . . . . . . . . . 15
8.5. Adding and Removing Flow Specifications . . . . . . . . . 14 8.5. Adding and Removing Flow Specifications . . . . . . . . . 15
8.6. VPN Identifiers . . . . . . . . . . . . . . . . . . . . . 15 8.6. VPN Identifiers . . . . . . . . . . . . . . . . . . . . . 15
8.7. Priorities and Overlapping Flow Specifications . . . . . 15 8.7. Priorities and Overlapping Flow Specifications . . . . . 16
9. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 15 9. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 18 10.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 19
10.1.1. PCEP FLOWSPEC Object Flag Field . . . . . . . . . . 18 10.1.1. PCEP FLOWSPEC Object Flag Field . . . . . . . . . . 19
10.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 19 10.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 20
10.3. Flow Specification TLV Type Indicators . . . . . . . . . 19 10.3. Flow Specification TLV Type Indicators . . . . . . . . . 20
10.4. PCEP Error Codes . . . . . . . . . . . . . . . . . . . . 20 10.4. PCEP Error Codes . . . . . . . . . . . . . . . . . . . . 21
10.5. PCE Capability Flag . . . . . . . . . . . . . . . . . . 21 10.5. PCE Capability Flag . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. Manageability Considerations . . . . . . . . . . . . . . . . 22 12. Manageability Considerations . . . . . . . . . . . . . . . . 23
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 12.1. Management of Multiple Flow Specifications . . . . . . . 23
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 12.2. Control of Function through Configuration and Policy . . 23
14.1. Normative References . . . . . . . . . . . . . . . . . . 22 12.3. Information and Data Models . . . . . . . . . . . . . . 24
14.2. Informative References . . . . . . . . . . . . . . . . . 23 12.4. Liveness Detection and Monitoring . . . . . . . . . . . 24
Appendix A. Flow Specification TLV Types . . . . . . . . . . . . 25 12.5. Verifying Correct Operation . . . . . . . . . . . . . . 24
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 27 12.6. Requirements on Other Protocols and Functional
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Components . . . . . . . . . . . . . . . . . . . . . . . 25
12.7. Impact on Network Operation . . . . . . . . . . . . . . 25
12.8. Other Considerations . . . . . . . . . . . . . . . . . . 25
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.1. Normative References . . . . . . . . . . . . . . . . . . 25
14.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Flow Specification TLV Types . . . . . . . . . . . . 28
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
[RFC4655] defines the Path Computation Element (PCE), a functional [RFC4655] defines the Path Computation Element (PCE), a functional
component capable of computing paths for use in traffic engineering component capable of computing paths for use in traffic engineering
networks. PCE was originally conceived for use in Multiprotocol networks. PCE was originally conceived for use in Multiprotocol
Label Switching (MPLS) for Traffic Engineering (TE) networks to Label Switching (MPLS) for Traffic Engineering (TE) networks to
derive the routes of Label Switched Paths (LSPs). However, the scope derive the routes of Label Switched Paths (LSPs). However, the scope
of PCE was quickly extended to make it applicable to Generalized MPLS of PCE was quickly extended to make it applicable to Generalized MPLS
(GMPLS) networks, and more recent work has brought other traffic (GMPLS) networks, and more recent work has brought other traffic
skipping to change at page 3, line 39 skipping to change at page 3, line 48
enable control of TE-LSPs by a PCE that retains state about the the enable control of TE-LSPs by a PCE that retains state about the the
LSPs provisioned in the network (a stateful PCE). [RFC8281] LSPs provisioned in the network (a stateful PCE). [RFC8281]
describes the setup, maintenance, and teardown of LSPs initiated by a describes the setup, maintenance, and teardown of LSPs initiated by a
stateful PCE without the need for local configuration on the PCC, stateful PCE without the need for local configuration on the PCC,
thus allowing for a dynamic network that is centrally controlled. thus allowing for a dynamic network that is centrally controlled.
[RFC8283] introduces the architecture for PCE as a central controller [RFC8283] introduces the architecture for PCE as a central controller
and describes how PCE can be viewed as a component that performs and describes how PCE can be viewed as a component that performs
computation to place 'flows' within the network and decide how these computation to place 'flows' within the network and decide how these
flows are routed. flows are routed.
Dissemination of traffic flow specifications (Flow Specifications) The description of traffic flows by the combination of multiple Flow
was introduced for BGP in [RFC5575]. A Flow Specification is Specification Components and their dissemination of as traffic flow
comprised of traffic filtering rules and actions. The routers that specifications (Flow Specifications) was introduced for BGP in
receive a Flow Specification can classify received packets according [RFC5575]. A Flow Specification is comprised of traffic filtering
to the traffic filtering rules and can direct packets based on the rules and actions. The routers that receive a Flow Specification can
actions. classify received packets according to the traffic filtering rules
and can direct packets based on the actions.
When a PCE is used to initiate tunnels (such as TE-LSPs or SR paths) When a PCE is used to initiate tunnels (such as TE-LSPs or SR paths)
using PCEP, it is important that the head end of the tunnels using PCEP, it is important that the head end of the tunnels
understands what traffic to place on each tunnel. The data flows understands what traffic to place on each tunnel. The data flows
intended for a tunnel can be described using Flow Specifications, and intended for a tunnel can be described using Flow Specification
when PCEP is in use for tunnel initiation it makes sense for that Components, and when PCEP is in use for tunnel initiation it makes
same protocol to be used to distribute the Flow Specifications that sense for that same protocol to be used to distribute the Flow
describe what data is to flow on those tunnels. Specification Components that describe what data is to flow on those
tunnels.
This document specifies a set of extensions to PCEP to support This document specifies a set of extensions to PCEP to support
dissemination of Flow Specifications. The extensions include the dissemination of Flow Specifications Components. For convenience we
creation, update, and withdrawal of Flow Specifications via PCEP, and term the description of a traffic flow using Flow Specification
can be applied to tunnels initiated by the PCE or to tunnels where Components as a "Flow Specification" and it must be understood that
control is delegated to the PCE by the PCC. Furthermore, a PCC this is not the same as the same term used in [RFC5575] since no
requesting a new path can include Flow Specifications in the request action is explicitly included in the encoding.
to indicate the purpose of the tunnel allowing the PCE to factor this
in during the path computation. The extensions defined in this document include the creation, update,
and withdrawal of Flow Specifications via PCEP, and can be applied to
tunnels initiated by the PCE or to tunnels where control is delegated
to the PCE by the PCC. Furthermore, a PCC requesting a new path can
include Flow Specifications in the request to indicate the purpose of
the tunnel allowing the PCE to factor this in during the path
computation.
Flow Specifications are carried in TLVs within a new Flow Spec Object Flow Specifications are carried in TLVs within a new Flow Spec Object
defined in this document. The flow filtering rules indicated by the defined in this document. The flow filtering rules indicated by the
Flow Specifications are mainly defined by BGP Flow Specifications. Flow Specifications are mainly defined by BGP Flow Specifications.
2. Terminology 2. Terminology
This document uses the following terms defined in [RFC5440]: PCC, This document uses the following terms defined in [RFC5440]: PCC,
PCE, PCEP Peer. PCE, PCEP Peer.
The following term from [RFC5575] is used frequently throughout this The following term from [RFC5575] is used frequently throughout this
document: document:
Flow Specification (FlowSpec): A Flow Specification is an n-tuple Flow Specification (FlowSpec): A Flow Specification is an n-tuple
consisting of several matching criteria that can be applied to IP consisting of several matching criteria that can be applied to IP
traffic, including filters and actions. Each FlowSpec consists of traffic, including filters and actions. Each FlowSpec consists of
a set of filters and a set of actions. a set of filters and a set of actions.
However, in the context of this document, no action is specified as
part of the FlowSpec since the action "forward all matching traffic
onto the associated path" is implicit.
This document uses the terms "stateful PCE" and "active PCE" as This document uses the terms "stateful PCE" and "active PCE" as
advocated in [RFC7399]. advocated in [RFC7399].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Procedures for PCE Use of Flow Specifications 3. Procedures for PCE Use of Flow Specifications
skipping to change at page 7, line 23 skipping to change at page 7, line 39
The inclusion of multiple PCEP FLOWSPEC Objects allows multiple The inclusion of multiple PCEP FLOWSPEC Objects allows multiple
traffic flows to be placed on a single path. traffic flows to be placed on a single path.
Once a PCE and PCC have established that they can both support the Once a PCE and PCC have established that they can both support the
use of Flow Specifications in PCEP messages, such information may be use of Flow Specifications in PCEP messages, such information may be
exchanged at any time for new or existing paths. exchanged at any time for new or existing paths.
The application and prioritization of Flow Specifications is The application and prioritization of Flow Specifications is
described in Section 8.7. described in Section 8.7.
As per [RFC8231], any attributes of the path received from a PCE are
subject to PCC's local policy, this holds good for the Flow
Specifications as well.
3.3. Flow Specification Synchronization 3.3. Flow Specification Synchronization
The Flow Specifications are carried along with the LSP State The Flow Specifications are carried along with the LSP State
information as per [RFC8231] making the Flow Specifications part of information as per [RFC8231] making the Flow Specifications part of
the LSP database (LSP-DB). Thus, the synchronization of the Flow the LSP database (LSP-DB). Thus, the synchronization of the Flow
Specification information is done as part of LSP-DB synchronization. Specification information is done as part of LSP-DB synchronization.
This may be achieved using normal state synchronization procedures as This may be achieved using normal state synchronization procedures as
described in [RFC8231] or enhanced state synchronization procedures described in [RFC8231] or enhanced state synchronization procedures
as defined in [RFC8232]. as defined in [RFC8232].
skipping to change at page 9, line 4 skipping to change at page 9, line 7
The PCEP FLOWSPEC object carries a FlowSpec filter rule encoded in a The PCEP FLOWSPEC object carries a FlowSpec filter rule encoded in a
TLV (as defined in Section 6. TLV (as defined in Section 6.
The FLOWSPEC Object-Class is TBD3 (to be assigned by IANA). The FLOWSPEC Object-Class is TBD3 (to be assigned by IANA).
The FLOWSPEC Object-Type is 1. The FLOWSPEC Object-Type is 1.
The format of the body of the PCEP FLOWSPEC object is shown in The format of the body of the PCEP FLOWSPEC object is shown in
Figure 2 Figure 2
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FS-ID | | FS-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI | Reserved | Flags |R| | AFI | Reserved | Flags |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Flow Filter TLV (variable) | // TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PCEP FLOWSPEC Object Body Format Figure 2: PCEP FLOWSPEC Object Body Format
FS-ID (32-bits): A PCEP-specific identifier for the FlowSpec FS-ID (32-bits): A PCEP-specific identifier for the FlowSpec
information. A PCE or PCC creates an FS-ID for each FlowSpec that it information. A PCE or PCC creates an FS-ID for each FlowSpec that it
originates, and the value is unique within the scope of that PCE or originates, and the value is unique within the scope of that PCE or
PCC and is constant for the lifetime of a PCEP session. All PCC and is constant for the lifetime of a PCEP session. All
subsequent PCEP messages can identify the FlowSpec using the FS-ID. subsequent PCEP messages can identify the FlowSpec using the FS-ID.
skipping to change at page 10, line 5 skipping to change at page 10, line 10
If the PCEP speaker receives a message with R bit set in FLOWSPEC If the PCEP speaker receives a message with R bit set in FLOWSPEC
object and the Flow Specification identified with a FS-ID does not object and the Flow Specification identified with a FS-ID does not
exist, it MUST generate a PCErr with Error-type TBD8 (FlowSpec exist, it MUST generate a PCErr with Error-type TBD8 (FlowSpec
Error), error-value 4 (Unknown FlowSpec). Error), error-value 4 (Unknown FlowSpec).
If the PCEP speaker does not understand or support the AFI in the If the PCEP speaker does not understand or support the AFI in the
FLOWSPEC message, the PCEP peer MUST respond with a PCErr message FLOWSPEC message, the PCEP peer MUST respond with a PCErr message
with error-type TBD8 (FlowSpec Error), error-value 2 (Malformed with error-type TBD8 (FlowSpec Error), error-value 2 (Malformed
FlowSpec). FlowSpec).
Flow Filter TLV (variable): One TLV MAY be included. Following TLVs can be used in the FLOWSPEC object:
The Flow Filter TLV is OPTIONAL when the R bit is set. The TLV MUST Speaker Entity Identifier TLV: As specified in [RFC8232], SPEAKER-
be present when the R bit is clear. If the TLV is missing when the R ENTITY-ID TLV encodes a unique identifier for the node that does
bit is clear, the PCEP peer MUST respond with a PCErr message with not change during the lifetime of the PCEP speaker. This is used
error-type TBD8 (FlowSpec Error), error-value 2 (Malformed FlowSpec). to uniquely identify the FlowSpec originator and thus used in
conjunction with FS-ID to uniquely idenfify the FlowSpec
information. This TLV MUST be included. If the TLV is missing,
the PCEP peer MUST respond with a PCErr message with error-type
TBD8 (FlowSpec Error), error-value 2 (Malformed FlowSpec).
Flow Filter TLV (variable): One TLV MAY be included. The Flow
Filter TLV is OPTIONAL when the R bit is set. The TLV MUST be
present when the R bit is clear. If the TLV is missing when the R
bit is clear, the PCEP peer MUST respond with a PCErr message with
error-type TBD8 (FlowSpec Error), error-value 2 (Malformed
FlowSpec).
6. Flow Filter TLV 6. Flow Filter TLV
A new PCEP TLV is defined to convey Flow Specification filtering A new PCEP TLV is defined to convey Flow Specification filtering
rules that specify what traffic is carried on a path. The TLV rules that specify what traffic is carried on a path. The TLV
follows the format of all PCEP TLVs as defined in [RFC5440]. The follows the format of all PCEP TLVs as defined in [RFC5440]. The
Type field values come from the codepoint space for PCEP TLVs and has Type field values come from the codepoint space for PCEP TLVs and has
the value TBD4. the value TBD4.
The Value field contains one or more sub-TLVs (the Flow Specification The Value field contains one or more sub-TLVs (the Flow Specification
skipping to change at page 12, line 13 skipping to change at page 12, line 24
action is to associate the traffic with a tunnel and to forward action is to associate the traffic with a tunnel and to forward
matching traffic on to that path, so no encoding of an action is matching traffic on to that path, so no encoding of an action is
needed. needed.
Section 8.7 describes how overlapping Flow Specifications are Section 8.7 describes how overlapping Flow Specifications are
prioritized and handled. prioritized and handled.
All Flow Specification TLVs with Types in the range 1 to 255 have All Flow Specification TLVs with Types in the range 1 to 255 have
Values defined for use in BGP (for example, in [RFC5575], Values defined for use in BGP (for example, in [RFC5575],
[I-D.ietf-idr-flow-spec-v6], and [I-D.ietf-idr-flowspec-l2vpn]) and [I-D.ietf-idr-flow-spec-v6], and [I-D.ietf-idr-flowspec-l2vpn]) and
are set using the BGP encoding, but without the type or length octets are set using the BGP encoding, but without the type octet (the
(the relevant information is in the Type and Length fields of the relevant information is in the Type field of the TLV). The Value
TLV). The Value field is padded with trailing zeros to achieve field is padded with trailing zeros to achieve 4-byte alignment.
4-byte alignment.
This document defines following new types - This document defines following new types -
+-------+-------------------------+-----------------------------+ +-------+-------------------------+-----------------------------+
| Type | Description | Value defined in | | Type | Description | Value defined in |
| | | | | | | |
+-------+-------------------------+-----------------------------+ +-------+-------------------------+-----------------------------+
| TBD5 | Route Distinguisher | [I-D.dhodylee-pce-pcep-ls] | | TBD5 | Route Distinguisher | [This.I-D] |
+-------+-------------------------+-----------------------------+ +-------+-------------------------+-----------------------------+
| TBD6 | IPv4 Multicast Flow | [This.I-D] | | TBD6 | IPv4 Multicast Flow | [This.I-D] |
+-------+-------------------------+-----------------------------+ +-------+-------------------------+-----------------------------+
| TBD7 | IPv6 Multicast Flow | [This.I-D] | | TBD7 | IPv6 Multicast Flow | [This.I-D] |
+-------+-------------------------+-----------------------------+ +-------+-------------------------+-----------------------------+
Figure 4: Table of Flow Specification TLV Types defined in this Figure 4: Table of Flow Specification TLV Types defined in this
document document
[I-D.dhodylee-pce-pcep-ls] defines a way to convey identification of To allow identification of a VPN in PCEP via a Route Distinguisher
a VPN in PCEP via a Route Distinguisher (RD) [RFC4364] encoded in (RD) [RFC4364] a new TLV - ROUTE-DISTINGUISHER TLV is defined in this
ROUTE-DISTINGUISHER TLV. A Flow Specification TLV with Type TBD5 document. A Flow Specification TLV with Type TBD5 (ROUTE-
carries a Value field matching that present in the ROUTE- DISTINGUISHER TLV) carries a RD Value, used to identify that other
DISTINGUISHER TLV and is used to identify that other flow filter flow filter information (for example, an IPv4 destination prefix) is
information (for example, an IPv4 destination prefix) is associated associated with a specific VPN identified by the RD. See Section 8.6
with a specific VPN identified by the RD. See Section 8.6 for for further discussion of VPN identification.
further discussion of VPN identification.
The format of the optional ROUTE-DISTINGUISHER TLV is shown in the
following figure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD5] | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of RD is as per [RFC4364].
Although it may be possible to describe a multicast Flow Although it may be possible to describe a multicast Flow
Specification from the combination of other Flow Specification TLVs Specification from the combination of other Flow Specification TLVs
with specific values, it is more convenient to use a dedicated Flow with specific values, it is more convenient to use a dedicated Flow
Specification TLV. Flow Specification TLVs with Type values TBD6 and Specification TLV. Flow Specification TLVs with Type values TBD6 and
TBD7 are used to identify a multicast flow for IPv4 and IPv6 TBD7 are used to identify a multicast flow for IPv4 and IPv6
respectively. The Value field is encoded as shown in Figure 5. respectively. The Value field is encoded as shown in Figure 5.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd |S|W|R| Rsvd |B|Z| Src Mask Len | Grp Mask Len | | Reserved | Src Mask Len | Grp Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Source Address ~ ~ Source Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group multicast Address ~ ~ Group multicast Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Multicast Flow Specification TLV Encoding Figure 5: Multicast Flow Specification TLV Encoding
The fields of the two Multicast Flow Specification TLVs are as The address fields and address mask lengths of the two Multicast Flow
described in Section 4.9.1 of [RFC7761] noting that the two address Specification TLVs are as described in Section 4.9.1 of [RFC7761]
fields are 32 bits for the IPv4 Multicast Flow and 128 bits for the noting that the two address fields are 32 bits for the IPv4 Multicast
IPv6 Multicast Flow. Reserved fields (RSVD) MUST be set to zero and Flow and 128 bits for the IPv6 Multicast Flow. The Reserved field
ignored on receipt. MUST be set to zero and ignored on receipt.
8. Detailed Procedures 8. Detailed Procedures
This section outlines some specific detailed procedures for using the This section outlines some specific detailed procedures for using the
protocol extensions defined in this document. protocol extensions defined in this document.
8.1. Default Behavior and Backward Compatibility 8.1. Default Behavior and Backward Compatibility
The default behavior is that no Flow Specification is applied to a The default behavior is that no Flow Specification is applied to a
tunnel. That is, the default is that the Flow Spec object is not tunnel. That is, the default is that the Flow Spec object is not
skipping to change at page 15, line 27 skipping to change at page 16, line 10
Thus the RD provides a useful way to indicate that traffic for a Thus the RD provides a useful way to indicate that traffic for a
particular VPN should be placed on a given tunnel. The tunnel head particular VPN should be placed on a given tunnel. The tunnel head
end will need to interpret this Flow Specification not as a filter on end will need to interpret this Flow Specification not as a filter on
the fields of data packets, but using the other mechanisms that it the fields of data packets, but using the other mechanisms that it
already uses to identify VPN traffic. This could be based on the already uses to identify VPN traffic. This could be based on the
incoming port (for port-based VPNs) or may leverage knowledge of the incoming port (for port-based VPNs) or may leverage knowledge of the
VRF that is in use for the traffic. VRF that is in use for the traffic.
8.7. Priorities and Overlapping Flow Specifications 8.7. Priorities and Overlapping Flow Specifications
TBD Flow specifications can overlap. For example, two different flow
specifications may be identical except for the length of the prefix
in the destination address. In these cases the PCC must determine
how to prioritise the flow specifications so as to know to which path
to assign packets that match both flow specifications. That is, the
PCC must assign a precedence to the flow specifications so that it
checks each incoming packet for a match in a predictable order.
The processing of BGP Flow Specifications is described in [RFC5575].
Section 5.1 of that document explains the order of traffic filtering
rules to be executed by an implementation of that specification.
PCCs MUST apply the same ordering rules as defined in [RFC5575].
Section 12.1 of this document covers manageability considerations
relevant to the prioritised ordering of flow specifications.
An implementation that receives a PCEP message carrying a Flow An implementation that receives a PCEP message carrying a Flow
Specification that it cannot resolve against other Flow Specification that it cannot resolve against other Flow
Specifications already installed MUST respond with a PCErr message Specifications already installed MUST respond with a PCErr message
with error-type TBD8 (FlowSpec Error), error-value 3 (Unresolvable with error-type TBD8 (FlowSpec Error), error-value 3 (Unresolvable
conflict) and MUST NOT install the Flow Specification. conflict) and MUST NOT install the Flow Specification.
9. PCEP Messages 9. PCEP Messages
The figures in this section use the notation defined in [RFC5511]. The figures in this section use the notation defined in [RFC5511].
skipping to change at page 22, line 7 skipping to change at page 23, line 7
they can become complex and that the overlap of Flow Specifications they can become complex and that the overlap of Flow Specifications
installed in different orders can lead to unexpected results. installed in different orders can lead to unexpected results.
Although this is not directly a security issue per se, the confusion Although this is not directly a security issue per se, the confusion
and unexpected forwarding behavior may be engineered or exploited by and unexpected forwarding behavior may be engineered or exploited by
an attacker. Therefore, implementers and operators SHOULD pay an attacker. Therefore, implementers and operators SHOULD pay
careful attention to the Manageability Considerations described in careful attention to the Manageability Considerations described in
Section 12. Section 12.
12. Manageability Considerations 12. Manageability Considerations
TBD The feature introduced by this document enables operational
manageability of networks operated in conjunction with a PCE and
using PCEP. Without this feature, but in the case of a stateful
active PCE or with PCE-initiated services, additional manual
configuration is needed to tell the head-ends what traffic to place
on the network services (LSPs, SR paths, etc.).
This section follows the advice and guidance of [RFC6123].
12.1. Management of Multiple Flow Specifications
Experience with flow specification in BGP suggests that there can be
a lot of complexity when two or more flow specifications overlap.
This can arise, for example, with addresses indicated using prefixes,
and could cause confusion about what traffic should be placed on
which path. Unlike the behavior in a distributed routing system, it
is not important that each head-end implementation applies the same
rules to disambiguate overlapping Flow Specifications, but it is
important that:
o A network operator can easily find out what traffic is being
placed on which path and why. This will facilitate analysis of
the network and diagnosis of faults.
o A PCE is able to correctly predict the effect of instructions it
gives to a PCC.
To that end, a PCC MUST enable an operator to view the the Flow
Specifications that it has installed, and these MUST be presented in
order of precedence such that when two Flow Specifications overlap,
the one that will be serviced with higher precedence is presented to
the operator first.
A discussion of precedence ordering for flow specifications is found
in Section 8.7.
12.2. Control of Function through Configuration and Policy
Support for the function described in this document implies that a
functional element that is capable of requesting a PCE to compute and
control a path is also able to configure the specification of what
traffic should be placed on that path. Where there is a human
involved in this action, configuration of the Flow Specification must
be available through an interface (such as a graphical user interface
or a command line interface). Where a distinct software component
(i.e., one not co-implemented with the PCE) is used, an protocol
mechanism will be required that could be PCEP itself or could be a
data model such as extensions to the YANG model for requesting path
computation [I-D.ietf-teas-yang-path-computation].
Implementations MAY be constructed with a configurable switch to say
whether they support the functions defined in this document.
Otherwise, such implementations MUST support indicate that they
support the function as described in Section 4. If an implementation
supports configurable support of this function, that support MAY be
configurable per peer or just once for the whole implementation.
As mentioned in Section 12.1, a PCE implementation SHOULD provide a
mechanism to configure variations in the precedence ordering of Flow
Specifications per PCC.
12.3. Information and Data Models
The YANG model in [I-D.ietf-pce-pcep-yang] can be used to model and
monitor PCEP states and messages. To make that YANG model useful for
the extensions described in this document it will need to be
augmented to cover the new protocol elements.
Similarly, as noted in Section 12.2, the YANG model defined in
[I-D.ietf-teas-yang-path-computation] could be extended to allow
specification of Flow Specifications.
Finally, as mentioned in Section 12.1, a PCC implementation SHOULD
provide a mechanism to allow an operator to read the Flow
Specifications from a PCC and to understand in what order they will
be executed. This could be achieved using a new YANG model.
12.4. Liveness Detection and Monitoring
The extensions defined in this document do not require any additional
liveness detection an monitoring support. See [RFC5440] and
[RFC5886] for more information.
12.5. Verifying Correct Operation
The chief element of operation that needs to be verified (in addition
to the operation of the protocol elements as described in [RFC5440])
is the installation, precedence, and correct operation of the Flow
Specifications at a PCC.
In addition to the YANG model for reading Flow Specifications
described in Section 12.3, tools may be needed to inject Operations
and Management (OAM) traffic at the PCC that matches specific
criteria so that it can be monitored as travelling along the desired
path. Such tools are outside the scope of this document.
12.6. Requirements on Other Protocols and Functional Components
This document places no requirements on other protocols or
components.
12.7. Impact on Network Operation
The use of the features described in this document clearly have an
important impact on network traffic since they cause traffic to be
routed on specific paths in the network. However, in practice, these
changes make no direct changes to the network operation because
traffic is already placed on those paths using some pre-existing
configuration mechanism. Thus, the significant change is the
reduction in mechanisms that have to be applied, rather than a change
to how the traffic is passed through the network.
12.8. Other Considerations
No other manageability considerations are known at this time.
13. Acknowledgements 13. Acknowledgements
Thanks to Julian Lucek and Sudhir Cheruathur for useful discussions. Thanks to Julian Lucek and Sudhir Cheruathur for useful discussions.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.dhodylee-pce-pcep-ls]
Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for
Distribution of Link-State and TE Information.", draft-
dhodylee-pce-pcep-ls-11 (work in progress), June 2018.
[I-D.ietf-idr-flow-spec-v6] [I-D.ietf-idr-flow-spec-v6]
McPherson, D., Raszuk, R., Pithawala, B., McPherson, D., Raszuk, R., Pithawala, B.,
akarch@cisco.com, a., and S. Hares, "Dissemination of Flow akarch@cisco.com, a., and S. Hares, "Dissemination of Flow
Specification Rules for IPv6", draft-ietf-idr-flow-spec- Specification Rules for IPv6", draft-ietf-idr-flow-spec-
v6-09 (work in progress), November 2017. v6-09 (work in progress), November 2017.
[I-D.ietf-idr-flowspec-l2vpn]
Weiguo, H., liangqiandeng, l., Uttaro, J., Litkowski, S.,
and S. Zhuang, "Dissemination of Flow Specification Rules
for L2 VPN", draft-ietf-idr-flowspec-l2vpn-08 (work in
progress), July 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007, DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>. <https://www.rfc-editor.org/info/rfc4760>.
skipping to change at page 23, line 22 skipping to change at page 26, line 32
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the "PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)", Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017, RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>. <https://www.rfc-editor.org/info/rfc8253>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-idr-flowspec-mpls-match] [I-D.ietf-idr-flowspec-l2vpn]
Yong, L., Hares, S., liangqiandeng, l., and J. You, "BGP Weiguo, H., Eastlake, D., Uttaro, J., Litkowski, S., and
Flow Specification Filter for MPLS Label", draft-ietf-idr- S. Zhuang, "BGP Dissemination of L2VPN Flow Specification
flowspec-mpls-match-01 (work in progress), December 2016. Rules", draft-ietf-idr-flowspec-l2vpn-09 (work in
progress), January 2019.
[I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", draft-ietf-pce-pcep-
yang-09 (work in progress), October 2018.
[I-D.ietf-pce-segment-routing] [I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing", and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-14 (work in progress), draft-ietf-pce-segment-routing-15 (work in progress),
October 2018. February 2019.
[I-D.ietf-teas-yang-path-computation]
Busi, I., Belotti, S., Lopezalvarez, V., Dios, O., Sharma,
A., Shi, Y., Vilata, R., Sethuraman, K., Scharf, M., and
D. Ceccarelli, "Yang model for requesting Path
Computation", draft-ietf-teas-yang-path-computation-04
(work in progress), November 2018.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "OSPF Protocol Extensions for Path Computation Zhang, "OSPF Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088,
January 2008, <https://www.rfc-editor.org/info/rfc5088>. January 2008, <https://www.rfc-editor.org/info/rfc5088>.
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "IS-IS Protocol Extensions for Path Computation Zhang, "IS-IS Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089,
January 2008, <https://www.rfc-editor.org/info/rfc5089>. January 2008, <https://www.rfc-editor.org/info/rfc5089>.
[RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of
Monitoring Tools for Path Computation Element (PCE)-Based
Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010,
<https://www.rfc-editor.org/info/rfc5886>.
[RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path
Computation Element (PCE) Working Group Drafts", RFC 6123,
DOI 10.17487/RFC6123, February 2011,
<https://www.rfc-editor.org/info/rfc6123>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<https://www.rfc-editor.org/info/rfc6952>. <https://www.rfc-editor.org/info/rfc6952>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399, Computation Element Architecture", RFC 7399,
DOI 10.17487/RFC7399, October 2014, DOI 10.17487/RFC7399, October 2014,
<https://www.rfc-editor.org/info/rfc7399>. <https://www.rfc-editor.org/info/rfc7399>.
skipping to change at page 25, line 9 skipping to change at page 28, line 44
[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An
Architecture for Use of PCE and the PCE Communication Architecture for Use of PCE and the PCE Communication
Protocol (PCEP) in a Network with Central Control", Protocol (PCEP) in a Network with Central Control",
RFC 8283, DOI 10.17487/RFC8283, December 2017, RFC 8283, DOI 10.17487/RFC8283, December 2017,
<https://www.rfc-editor.org/info/rfc8283>. <https://www.rfc-editor.org/info/rfc8283>.
Appendix A. Flow Specification TLV Types Appendix A. Flow Specification TLV Types
[Editor's Note: This section is added for illustration of various [Editor's Note: This section is added for illustration of various
Types supported, some are inherited from BGP and others are defined Types supported, some are inherited from BGP and others are defined
in this document. This section might be removed at the time of final in this document. This section may be removed at the time of final
publication.] publication.]
+-------+-------------------------+-----------------------------+ +-------+-------------------------+-----------------------------+
| Type | Description | Value defined in | | Type | Description | Value defined in |
| | | | | | | |
+-------+-------------------------+-----------------------------+ +-------+-------------------------+-----------------------------+
| * | Destination IPv4 Prefix | [RFC5575] | | * | Destination IPv4 Prefix | [RFC5575] |
+-------+-------------------------+-----------------------------+ +-------+-------------------------+-----------------------------+
| * | Destination IPv6 Prefix | [I-D.ietf-idr-flow-spec-v6] | | * | Destination IPv6 Prefix | [I-D.ietf-idr-flow-spec-v6] |
+-------+-------------------------+-----------------------------+ +-------+-------------------------+-----------------------------+
skipping to change at page 26, line 36 skipping to change at page 30, line 23
+-------+-------------------------+-----------------------------+ +-------+-------------------------+-----------------------------+
| * | Inner VLAN ID | [I-D.ietf-idr-flowspec- | | * | Inner VLAN ID | [I-D.ietf-idr-flowspec- |
| | | l2vpn] | | | | l2vpn] |
+-------+-------------------------+-----------------------------+ +-------+-------------------------+-----------------------------+
| * | Inner VLAN COS | [I-D.ietf-idr-flowspec- | | * | Inner VLAN COS | [I-D.ietf-idr-flowspec- |
| | | l2vpn] | | | | l2vpn] |
+-------+-------------------------+-----------------------------+ +-------+-------------------------+-----------------------------+
| * | MPLS Label | [I-D.ietf-idr-flowspec-mpls-| | * | MPLS Label | [I-D.ietf-idr-flowspec-mpls-|
| | | match] | | | | match] |
+-------+-------------------------+-----------------------------+ +-------+-------------------------+-----------------------------+
| TBD5 | Route Distinguisher | [I-D.dhodylee-pce-pcep-ls] | | TBD5 | Route Distinguisher | [This.I-D] |
+-------+-------------------------+-----------------------------+ +-------+-------------------------+-----------------------------+
| TBD6 | IPv4 Multicast Flow | [This.I-D] | | TBD6 | IPv4 Multicast Flow | [This.I-D] |
+-------+-------------------------+-----------------------------+ +-------+-------------------------+-----------------------------+
| TBD7 | IPv6 Multicast Flow | [This.I-D] | | TBD7 | IPv6 Multicast Flow | [This.I-D] |
+-------+-------------------------+-----------------------------+ +-------+-------------------------+-----------------------------+
* Indicates that the TLV Type value comes from the value used * Indicates that the TLV Type value comes from the value used
in BGP. in BGP.
This is a non-exhaustive list for illustration purpose. This is a non-exhaustive list for illustration purpose.
skipping to change at page 28, line 15 skipping to change at page 31, line 48
Shunwan Zhuang Shunwan Zhuang
Huawei Technologies Huawei Technologies
Huawei Bld., No.156 Beiqing Rd. Huawei Bld., No.156 Beiqing Rd.
Beijing Beijing
100095 100095
China China
Email: zhuangshunwan@huawei.com Email: zhuangshunwan@huawei.com
Cheng Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: chengli13@huawei.com
Authors' Addresses Authors' Addresses
Dhruv Dhody (editor) Dhruv Dhody
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore, Karnataka 560066
India India
Email: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
Adrian Farrel (editor) Adrian Farrel
Juniper Networks Old Dog Consulting
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
Zhenbin Li Zhenbin Li
Huawei Technologies Huawei Technologies
Huawei Bld., No.156 Beiqing Rd. Huawei Bld., No.156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: lizhenbin@huawei.com Email: lizhenbin@huawei.com
 End of changes. 39 change blocks. 
101 lines changed or deleted 302 lines changed or added

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