< draft-ietf-pce-pcep-flowspec-05.txt.orig   draft-ietf-pce-pcep-flowspec-05.txt >
skipping to change at page 1, line 17 skipping to change at page 1, line 17
Z. Li Z. Li
Huawei Technologies Huawei Technologies
August 15, 2019 August 15, 2019
PCEP Extension for Flow Specification PCEP Extension for Flow Specification
draft-ietf-pce-pcep-flowspec-05 draft-ietf-pce-pcep-flowspec-05
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 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 Flow Specification Components are used to describe describes how Flow Specification Components are used to describe
traffic flows. RFC 5575 also defines how Flow Specifications may be traffic flows. RFC 5575 also defines how Flow Specifications may be
distributed in BGP to allow specific traffic flows to be associated distributed in BGP to allow specific traffic flows to be associated
skipping to change at page 3, line 49 skipping to change at page 3, line 49
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.
The description of traffic flows by the combination of multiple Flow The description of traffic flows by the combination of multiple Flow
Specification Components and their dissemination of as traffic flow Specification Components and their dissemination as traffic flow
specifications (Flow Specifications) was introduced for BGP in specifications (Flow Specifications) was introduced for BGP in
[RFC5575] and updated (for clarification) in [RFC7674]. A Flow [RFC5575] and updated (for clarification) in [RFC7674]. A Flow
Specification is comprised of traffic filtering rules and actions. Specification is comprised of traffic filtering rules and actions.
The routers that receive a Flow Specification can classify received The routers that receive a Flow Specification can classify received
packets according to the traffic filtering rules and can direct packets according to the traffic filtering rules and can direct
packets based on the actions. 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
skipping to change at page 4, line 30 skipping to change at page 4, line 30
term the description of a traffic flow using Flow Specification term the description of a traffic flow using Flow Specification
Components as a "Flow Specification" and it must be understood that Components as a "Flow Specification" and it must be understood that
this is not the same as the same term used in [RFC5575] since no this is not the same as the same term used in [RFC5575] since no
action is explicitly included in the encoding. action is explicitly included in the encoding.
The extensions defined in this document include the creation, update, The extensions defined in this document include the creation, update,
and withdrawal of Flow Specifications via PCEP, and can be applied to and withdrawal of Flow Specifications via PCEP, and can be applied to
tunnels initiated by the PCE or to tunnels where control is delegated 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 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 include Flow Specifications in the request to indicate the purpose of
the tunnel allowing the PCE to factor this in during the path the tunnel allowing the PCE to factor this into the path
computation. 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.
skipping to change at page 6, line 39 skipping to change at page 6, line 39
3.2.1.1. PCEP OPEN Message 3.2.1.1. PCEP OPEN Message
During PCEP session establishment, a PCC or PCE that supports the During PCEP session establishment, a PCC or PCE that supports the
procedures described in this document announces this fact by procedures described in this document announces this fact by
including the "PCE FlowSpec Capability" TLV (described in Section 4) including the "PCE FlowSpec Capability" TLV (described in Section 4)
in the OPEN Object carried in the PCEP Open message. in the OPEN Object carried in the PCEP Open message.
The presence of the PCE FlowSpec Capability TLV in the OPEN Object in The presence of the PCE FlowSpec Capability TLV in the OPEN Object in
a PCE's OPEN message indicates that the PCE can distribute FlowSpecs a PCE's OPEN message indicates that the PCE can distribute FlowSpecs
to PCCs and can receive FlowSpecs in messages from the PCCs. to PCCs and can receive FlowSpecs in messages from PCCs.
The presence of the PCE FlowSpec Capability TLV in the OPEN Object in The presence of the PCE FlowSpec Capability TLV in the OPEN Object in
a PCC's OPEN message indicates that the PCC supports the FlowSpec a PCC's OPEN message indicates that the PCC supports the FlowSpec
functionality described in this document. functionality described in this document.
If either one of a pair of PCEP peers does not indicate support of If either one of a pair of PCEP peers does not indicate support of
the functionality described in this document by not including the PCE the functionality described in this document by not including the PCE
FlowSpec Capability TLV in the OPEN Object in its OPEN message, then FlowSpec Capability TLV in the OPEN Object in its OPEN message, then
the other peer MUST NOT include a FlowSpec object in any PCEP message the other peer MUST NOT include a FlowSpec object in any PCEP message
sent to the peer that does not support the procedures. If a FlowSpec sent to the peer that does not support the procedures. If a FlowSpec
object is received even though support has not been indicated, the object is received when support has not been indicated, the
receiver will respond with a PCErr message reporting the objects receiver will respond with a PCErr message reporting the objects
containing the FlowSpec as described in [RFC5440]: that is, it will containing the FlowSpec as described in [RFC5440]: that is, it will
use 'Unknown Object' if it does not support this specification, and use 'Unknown Object' if it does not support this specification, and
'Not supported object' if it supports this specification but has not 'Not supported object' if it supports this specification but has not
chosen to support FlowSpec objects on this PCEP session. chosen to support FlowSpec objects on this PCEP session.
3.2.1.2. IGP PCE Capabilities Advertisement 3.2.1.2. IGP PCE Capabilities Advertisement
The ability to advertise support for PCEP and PCE features in IGP The ability to advertise support for PCEP and PCE features in IGP
advertisements is provided for OSPF in [RFC5088] and for IS-IS in advertisements is provided for OSPF in [RFC5088] and for IS-IS in
skipping to change at page 9, line 8 skipping to change at page 9, line 8
described in [RFC8231] or enhanced state synchronization procedures described in [RFC8231] or enhanced state synchronization procedures
as defined in [RFC8232]. as defined in [RFC8232].
The approach selected will be implementation and deployment specific The approach selected will be implementation and deployment specific
and will depend on issues such as how the databases are constructed and will depend on issues such as how the databases are constructed
and what level of synchronization support is needed. and what level of synchronization support is needed.
4. PCE FlowSpec Capability TLV 4. PCE FlowSpec Capability TLV
The PCE-FLOWSPEC-CAPABILITY TLV is an optional TLV that can be The PCE-FLOWSPEC-CAPABILITY TLV is an optional TLV that can be
carried in the OPEN Object [RFC5440] to exchange PCE FlowSpec carried in the OPEN Object [RFC5440] to exchange the PCE FlowSpec
capabilities of PCEP speakers. capabilities of PCEP speakers.
The format of the PCE-FLOWSPEC-CAPABILITY TLV follows the format of The format of the PCE-FLOWSPEC-CAPABILITY TLV follows the format of
all PCEP TLVs as defined in [RFC5440] and is shown in Figure 1. all PCEP TLVs as defined in [RFC5440] and is shown in Figure 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD2 | Length=2 | | Type=TBD2 | Length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 40 skipping to change at page 9, line 40
5. PCEP FLOWSPEC Object 5. PCEP FLOWSPEC Object
The PCEP FLOWSPEC object defined in this document is compliant with The PCEP FLOWSPEC object defined in this document is compliant with
the PCEP object format defined in [RFC5440]. It is OPTIONAL in the the PCEP object format defined in [RFC5440]. It is OPTIONAL in the
PCReq, PCRep, PCErr, PCInitiate, PCRpt, and PCUpd messages and MAY be PCReq, PCRep, PCErr, PCInitiate, PCRpt, and PCUpd messages and MAY be
present zero, one, or more times. Each instance of the object present zero, one, or more times. Each instance of the object
specifies a traffic flow. specifies a traffic flow.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 46 skipping to change at page 11, line 46
of Flow Specification TLVs in a single instance of a Flow Filter TLV of Flow Specification TLVs in a single instance of a Flow Filter TLV
are combined to indicate the specific Flow Specification. are combined to indicate the specific Flow Specification.
Further Flow Specifications can be included in a PCEP message by Further Flow Specifications can be included in a PCEP message by
including additional Flow Spec objects. including additional Flow Spec objects.
7. Flow Specification TLVs 7. Flow Specification TLVs
The Flow Filter TLV carries one or more Flow Specification TLV. The The Flow Filter TLV carries one or more Flow Specification TLV. The
Flow Specification TLV follows the format of all PCEP TLVs as defined Flow Specification TLV follows the format of all PCEP TLVs as defined
in [RFC5440], however, the Type values are selected from a separate in [RFC5440]. However, the Type values are selected from a separate
IANA registry (see Section 10) rather than from the common PCEP TLV IANA registry (see Section 10) rather than from the common PCEP TLV
registry. registry.
Type values are chosen so that there can be commonality with Flow Type values are chosen so that there can be commonality with Flow
Specifications defined for use with BGP [RFC5575]. This is possible Specifications defined for use with BGP [RFC5575]. This is possible
because the BGP Flow Spec encoding uses a single octet to encode the because the BGP Flow Spec encoding uses a single octet to encode the
type where as PCEP uses two octets. Thus the space of values for the type where as PCEP uses two octets. Thus the space of values for the
Type field is partitioned as shown in Figure 3. Type field is partitioned as shown in Figure 3.
Range | Range |
skipping to change at page 12, line 29 skipping to change at page 12, line 29
[RFC5575] created the registry "Flow Spec Component Types" and made [RFC5575] created the registry "Flow Spec Component Types" and made
allocations to it. [I-D.ietf-idr-flow-spec-v6] requested for another allocations to it. [I-D.ietf-idr-flow-spec-v6] requested for another
registry "Flow Spec IPv6 Component Types" and requested initial registry "Flow Spec IPv6 Component Types" and requested initial
allocations in it. If the AFI (in the FLOWSPEC object) is set to allocations in it. If the AFI (in the FLOWSPEC object) is set to
IPv4, the range 1..255 is as per "Flow Spec Component Types" IPv4, the range 1..255 is as per "Flow Spec Component Types"
[RFC5575]; if the AFI is set to IPv6, the range 1..255 is as per [RFC5575]; if the AFI is set to IPv6, the range 1..255 is as per
"Flow Spec IPv6 Component Types" [I-D.ietf-idr-flow-spec-v6]. When "Flow Spec IPv6 Component Types" [I-D.ietf-idr-flow-spec-v6]. When
future BGP specifications (such as [I-D.ietf-idr-flowspec-l2vpn]) future BGP specifications (such as [I-D.ietf-idr-flowspec-l2vpn])
make further allocations to the aforementioned registries, they are make further allocations to the aforementioned registries, they are
also inherited to be used in PCEP. also inherited for PCEP usage.
The content of the Value field in each TLV is specific to the type/ The content of the Value field in each TLV is specific to the type/
AFI and describes the parameters of the Flow Specification. The AFI and describes the parameters of the Flow Specification. The
definition of the format of many of these Value fields is inherited definition of the format of many of these Value fields is inherited
from BGP specifications. Specifically, the inheritance is from from BGP specifications. Specifically, the inheritance is from
[RFC5575] and [I-D.ietf-idr-flow-spec-v6], but may also be inherited [RFC5575] and [I-D.ietf-idr-flow-spec-v6], but may also be inherited
from future BGP specifications. from future BGP specifications.
When multiple Flow Specification TLVs are present in a single Flow When multiple Flow Specification TLVs are present in a single Flow
Filter TLV they are combined to produce a more detailed description Filter TLV they are combined to produce a more detailed specification
of a flow. For examples and rules about how this is achieved, see of a flow. For examples and rules about how this is achieved, see
[RFC5575]. [RFC5575].
An implementation that receives a PCEP message carrying a Flow An implementation that receives a PCEP message carrying a Flow
Specification TLV with a type value that it does not recognize or Specification TLV with a type value that it does not recognize or
does not support MUST respond with a PCErr message with error-type does not support MUST respond with a PCErr message with error-type
TBD8 (FlowSpec Error), error-value 1 (Unsupported FlowSpec) and MUST TBD8 (FlowSpec Error), error-value 1 (Unsupported FlowSpec) and MUST
NOT install the Flow Specification. NOT install the Flow Specification.
When used in other protocols (such as BGP) these Flow Specifications When used in other protocols (such as BGP), these Flow Specifications
are also associated with actions to indicate how traffic matching the are also associated with actions to indicate how traffic matching the
Flow Specification should be treated. In PCEP, however, the only Flow Specification should be treated. In PCEP, however, the only
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 onto 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 octet (the are set using the BGP encoding, but without the type octet (the
relevant information is in the Type field of the TLV). The Value relevant information is in the Type field of the TLV). The Value
skipping to change at page 13, line 39 skipping to change at page 13, line 39
+-------+-------------------------+-----------------------------+ +-------+-------------------------+-----------------------------+
| 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
To allow identification of a VPN in PCEP via a Route Distinguisher To allow identification of a VPN in PCEP via a Route Distinguisher
(RD) [RFC4364] a new TLV - ROUTE-DISTINGUISHER TLV is defined in this (RD) [RFC4364], a new TLV - ROUTE-DISTINGUISHER TLV is defined in this
document. A Flow Specification TLV with Type TBD5 (ROUTE- document. A Flow Specification TLV with Type TBD5 (ROUTE-
DISTINGUISHER TLV) carries a RD Value, used to identify that other DISTINGUISHER TLV) carries an RD Value, used to identify that other
flow filter information (for example, an IPv4 destination prefix) is flow filter information (for example, an IPv4 destination prefix) is
associated with a specific VPN identified by the RD. See Section 8.6 associated with a specific VPN identified by the RD. See Section 8.6
for further discussion of VPN identification. for further discussion of VPN identification.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD5] | Length=8 | | Type=[TBD5] | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
skipping to change at page 14, line 40 skipping to change at page 14, line 40
~ Source Address ~ ~ Source Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group multicast Address ~ ~ Group multicast Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Multicast Flow Specification TLV Encoding Figure 6: Multicast Flow Specification TLV Encoding
The address fields and address mask lengths of the two Multicast Flow The address fields and address mask lengths of the two Multicast Flow
Specification TLVs contain source and group prefixes for matching Specification TLVs contain source and group prefixes for matching
against packet flows noting that the two address fields are 32 bits against packet flows noting that the two address fields are 32 bits
for the IPv4 Multicast Flow and 128 bits for the IPv6 Multicast Flow. for an IPv4 Multicast Flow and 128 bits for am IPv6 Multicast Flow.
The Reserved field MUST be set to zero and ignored on receipt. The Reserved field MUST be set to zero and ignored on receipt.
Two flags (S and G) are defined. They have the common meanings for Two bit flags (S and G) are defined. They have the common meanings for
wildcarding in multicast. If the S bit is set, then source wildcarding in multicast. If the S bit is set, then source
wildcarding is in use and the values in the Source Mask Length and wildcarding is in use and the values in the Source Mask Length and
Source Address fields MUST be ignored. If the G bit is set, then Source Address fields MUST be ignored. If the G bit is set, then
group wildcarding is in use and the values in the Group Mask Length group wildcarding is in use and the values in the Group Mask Length
and Group multicast Address fields MUST be ignored. The G bit MUST and Group multicast Address fields MUST be ignored. The G bit MUST
NOT be set unless the S bit is also set: if a Multicast Flow NOT be set unless the S bit is also set: if a Multicast Flow
Specification TLV is received with S bit = 0 and G bit = 1 the Specification TLV is received with S bit = 0 and G bit = 1 the
receiver SHOULD respond with a PCErr with Error-type TBD8 (FlowSpec receiver SHOULD respond with a PCErr with Error-type TBD8 (FlowSpec
Error) and error-value 2 (Malformed FlowSpec). Error) and error-value 2 (Malformed FlowSpec).
skipping to change at page 15, line 33 skipping to change at page 15, line 33
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
used as is the case in all systems before the implementation of this used as is the case in all systems before the implementation of this
specification. specification.
In this case it is a local matter (such as through configuration) how In this case, it is a local matter (such as through configuration) how
tunnel head ends are instructed what traffic to place on a tunnel. tunnel head ends are instructed what traffic to place on a tunnel.
[RFC5440] describes how receivers respond when they see unknown PCEP [RFC5440] describes how receivers respond when they see unknown PCEP
objects. objects.
8.2. Composite Flow Specifications 8.2. Composite Flow Specifications
Flow Specifications may be represented by a single Flow Specification Flow Specifications may be represented by a single Flow Specification
TLV or may require a more complex description using multiple Flow TLV or may require a more complex description using multiple Flow
Specification TLVs. For example, a flow indicated by a source- Specification TLVs. For example, a flow indicated by a source-
skipping to change at page 16, line 50 skipping to change at page 16, line 50
8.5. Adding and Removing Flow Specifications 8.5. Adding and Removing Flow Specifications
The Remove bit in the the PCEP Flow Spec Object is left clear when a The Remove bit in the the PCEP Flow Spec Object is left clear when a
Flow Specification is being added or modified. Flow Specification is being added or modified.
To remove a Flow Specification, a PCEP Flow Spec Object is included To remove a Flow Specification, a PCEP Flow Spec Object is included
with the FS-ID matching the one being removed, and the R bit set to with the FS-ID matching the one being removed, and the R bit set to
indicate removal. In this case it is not necessary to include any indicate removal. In this case it is not necessary to include any
Flow Specification TLVs. Flow Specification TLVs.
If the R bit is set and Flow Specification TLVs are present an If the R bit is set and Flow Specification TLVs are present, an
implementation MAY ignore them. If the implementation checks the implementation MAY ignore them. If the implementation checks the
Flow Specification TLVs against those recorded for the FS-ID of the Flow Specification TLVs against those recorded for the FS-ID of the
Flow Specification being removed and finds a mismatch, the Flow Flow Specification being removed and finds a mismatch, the Flow
Specification MUST still be removed and the implementation SHOULD Specification MUST still be removed and the implementation SHOULD
record a local exception or log. record a local exception or log.
8.6. VPN Identifiers 8.6. VPN Identifiers
VPN instances are identified in BGP using Route Distinguishers (RDs) VPN instances are identified in BGP using Route Distinguishers (RDs)
[RFC4364]. These values are not normally considered to have any [RFC4364]. These values are not normally considered to have any
skipping to change at page 24, line 31 skipping to change at page 24, line 31
misrouted within the network. Therefore, the use of the security misrouted within the network. Therefore, the use of the security
mechanisms for PCEP referenced above is important. mechanisms for PCEP referenced above is important.
Visibility into the information carried in PCEP does not have direct Visibility into the information carried in PCEP does not have direct
privacy concerns for end-users' data, however, knowledge of how data privacy concerns for end-users' data, however, knowledge of how data
is routed in a network may make that data more vulnerable. Of is routed in a network may make that data more vulnerable. Of
course, the ability to interfere with the way data is routed also course, the ability to interfere with the way data is routed also
makes the data more vulnerable. Furthermore, knowledge of the makes the data more vulnerable. Furthermore, knowledge of the
connected end-points (such as multicast receivers or VPN sites) is connected end-points (such as multicast receivers or VPN sites) is
usually considered private customer information. Therefore, usually considered private customer information. Therefore,
implementations or deployments concerned to protect privacy MUST implementations or deployments concerned with protecting privacy MUST
apply the mechanisms described in the documents referenced above. apply the mechanisms described in the documents referenced above.
Experience with Flow Specifications in BGP systems indicates that Experience with Flow Specifications in BGP systems indicates that
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 13. Section 13.
skipping to change at page 25, line 41 skipping to change at page 25, line 41
13.2. Control of Function through Configuration and Policy 13.2. Control of Function through Configuration and Policy
Support for the function described in this document implies that a Support for the function described in this document implies that a
functional element that is capable of requesting a PCE to compute and functional element that is capable of requesting a PCE to compute and
control a path is also able to configure the specification of what control a path is also able to configure the specification of what
traffic should be placed on that path. Where there is a human traffic should be placed on that path. Where there is a human
involved in this action, configuration of the Flow Specification must involved in this action, configuration of the Flow Specification must
be available through an interface (such as a graphical user interface be available through an interface (such as a graphical user interface
or a command line interface). Where a distinct software component or a command line interface). Where a distinct software component
(i.e., one not co-implemented with the PCE) is used, an protocol (i.e., one not co-implemented with the PCE) is used, a protocol
mechanism will be required that could be PCEP itself or could be a 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 data model such as extensions to the YANG model for requesting path
computation [I-D.ietf-teas-yang-path-computation]. computation [I-D.ietf-teas-yang-path-computation].
Implementations MAY be constructed with a configurable switch to say Implementations MAY be constructed with a configurable switch to say
whether they support the functions defined in this document. whether they support the functions defined in this document.
Otherwise, such implementations MUST support indicate that they Otherwise, such implementations MUST support indication that they
support the function as described in Section 4. If an implementation support the function as described in Section 4. If an implementation
supports configurable support of this function, that support MAY be supports configurable support of this function, that support MAY be
configurable per peer or just once for the whole implementation. configurable per peer or once for the whole implementation.
As mentioned in Section 13.1, a PCE implementation SHOULD provide a As mentioned in Section 13.1, a PCE implementation SHOULD provide a
mechanism to configure variations in the precedence ordering of Flow mechanism to configure variations in the precedence ordering of Flow
Specifications per PCC. Specifications per PCC.
13.3. Information and Data Models 13.3. Information and Data Models
The YANG model in [I-D.ietf-pce-pcep-yang] can be used to model and 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 monitor PCEP states and messages. To make that YANG model useful for
the extensions described in this document it will need to be the extensions described in this document, it will need to be
augmented to cover the new protocol elements. augmented to cover the new protocol elements.
Similarly, as noted in Section 13.2, the YANG model defined in Similarly, as noted in Section 13.2, the YANG model defined in
[I-D.ietf-teas-yang-path-computation] could be extended to allow [I-D.ietf-teas-yang-path-computation] could be extended to allow
specification of Flow Specifications. specification of Flow Specifications.
Finally, as mentioned in Section 13.1, a PCC implementation SHOULD Finally, as mentioned in Section 13.1, a PCC implementation SHOULD
provide a mechanism to allow an operator to read the Flow provide a mechanism to allow an operator to read the Flow
Specifications from a PCC and to understand in what order they will Specifications from a PCC and to understand in what order they will
be executed. This could be achieved using a new YANG model. be executed. This could be achieved using a new YANG model.
13.4. Liveness Detection and Monitoring 13.4. Liveness Detection and Monitoring
The extensions defined in this document do not require any additional The extensions defined in this document do not require any additional
liveness detection an monitoring support. See [RFC5440] and liveness detection and monitoring support. See [RFC5440] and
[RFC5886] for more information. [RFC5886] for more information.
13.5. Verifying Correct Operation 13.5. Verifying Correct Operation
The chief element of operation that needs to be verified (in addition The chief element of operation that needs to be verified (in addition
to the operation of the protocol elements as described in [RFC5440]) to the operation of the protocol elements as described in [RFC5440])
is the installation, precedence, and correct operation of the Flow is the installation, precedence, and correct operation of the Flow
Specifications at a PCC. Specifications at a PCC.
In addition to the YANG model for reading Flow Specifications In addition to the YANG model for reading Flow Specifications
described in Section 13.3, tools may be needed to inject Operations described in Section 13.3, tools may be needed to inject Operations
and Management (OAM) traffic at the PCC that matches specific and Management (OAM) traffic at the PCC that matches specific
criteria so that it can be monitored as travelling along the desired criteria so that it can be monitored as traveling along the desired
path. Such tools are outside the scope of this document. path. Such tools are outside the scope of this document.
13.6. Requirements on Other Protocols and Functional Components 13.6. Requirements on Other Protocols and Functional Components
This document places no requirements on other protocols or This document places no requirements on other protocols or
components. components.
13.7. Impact on Network Operation 13.7. Impact on Network Operation
The use of the features described in this document clearly have an The use of the features described in this document clearly have an
 End of changes. 25 change blocks. 
25 lines changed or deleted 25 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/