< 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/ |