draft-ietf-teas-rsvp-te-srlg-collect-06.txt   draft-ietf-teas-rsvp-te-srlg-collect-07.txt 
TEAS Working Group F. Zhang, Ed. TEAS Working Group F. Zhang, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track O. Gonzalez de Dios, Ed. Intended status: Standards Track O. Gonzalez de Dios, Ed.
Expires November 26, 2016 Telefonica Global CTO Expires February 16, 2017 Telefonica Global CTO
M. Hartley M. Hartley
Z. Ali Z. Ali
Cisco Cisco
C. Margaria C. Margaria
May 26, 2016 August 16, 2016
RSVP-TE Extensions for Collecting SRLG Information RSVP-TE Extensions for Collecting SRLG Information
draft-ietf-teas-rsvp-te-srlg-collect-06 draft-ietf-teas-rsvp-te-srlg-collect-07
Abstract Abstract
This document provides extensions for the Resource ReserVation This document provides extensions for the Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to support Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to support
automatic collection of Shared Risk Link Group (SRLG) information for automatic collection of Shared Risk Link Group (SRLG) information for
the TE link formed by a Label Switched Path (LSP). the TE link formed by a Label Switched Path (LSP).
Status of This Memo Status of This Memo
skipping to change at page 2, line 28 skipping to change at page 2, line 28
3.4. SRLG ID definition . . . . . . . . . . . . . . . . . . . . 6 3.4. SRLG ID definition . . . . . . . . . . . . . . . . . . . . 6
4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . . 6 4.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . . 6
4.2. RRO SRLG sub-object . . . . . . . . . . . . . . . . . . . 6 4.2. RRO SRLG sub-object . . . . . . . . . . . . . . . . . . . 6
5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . . 8 5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . . 8
5.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 8 5.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 8
5.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 10
5.3 Domain Boundaries . . . . . . . . . . . . . . . . . . . . . 10 5.3 Domain Boundaries . . . . . . . . . . . . . . . . . . . . . 10
5.4. Compatibility . . . . . . . . . . . . . . . . . . . . . . 10 5.4. Compatibility . . . . . . . . . . . . . . . . . . . . . . 10
6. Manageability Considerations . . . . . . . . . . . . . . . . . 10 6. Manageability Considerations . . . . . . . . . . . . . . . . . 10
6.1. Policy Configuration . . . . . . . . . . . . . . . . . . . 10 6.1. Policy Configuration . . . . . . . . . . . . . . . . . . . 11
6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 11 6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . . 11 8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . . 11
8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 12 8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 12
8.3. Policy Control Failure Error subcodes . . . . . . . . . . 12 8.3. Policy Control Failure Error subcodes . . . . . . . . . . 12
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
It is important to understand which Traffic Engineering (TE) links in It is important to understand which Traffic Engineering (TE) links in
the network might be at risk from the same failures. In this sense, the network might be at risk from the same failures. In this sense,
a set of links can constitute a 'shared risk link group' (SRLG) if a set of links can constitute a 'shared risk link group' (SRLG) if
skipping to change at page 6, line 21 skipping to change at page 6, line 21
The identifier of an SRLG (SRLG ID) is defined as a 32-bit quantity The identifier of an SRLG (SRLG ID) is defined as a 32-bit quantity
in [RFC4202]. This definition is used in this document. in [RFC4202]. This definition is used in this document.
4. Encodings 4. Encodings
4.1. SRLG Collection Flag 4.1. SRLG Collection Flag
In order to indicate to nodes that SRLG collection is desired, this In order to indicate to nodes that SRLG collection is desired, this
document defines a new flag in the Attribute Flags TLV (see RFC 5420 document defines a new flag in the Attribute Flags TLV (see RFC 5420
[RFC5420]), which MAY be carried in an LSP_REQUIRED_ATTRIBUTES or [RFC5420]). This document defines a new SRLG collection flag in the
LSP_ATTRIBUTES Object: Attribute Flags TLV (see RFC 5420 [RFC5420]). A node that wishes to
indicate that SRLG collection is desired MUST set this flag in an
Attribute Flags TLV in an LSP_REQUIRED_ATTRIBUTES Object if
collection is to be mandatory, or an LSP_ATTRIBUTES Object if
collection is desired but not mandatory.
o Bit Number (specified in Section 8.1): SRLG Collection flag o Bit Number (specified in Section 8.1): SRLG Collection flag
The SRLG Collection flag is meaningful on a Path message. If the The SRLG Collection flag is meaningful on a Path message. If the
SRLG Collection flag is set to 1, it means that the SRLG information SRLG Collection flag is set to 1, it means that the SRLG information
SHOULD be reported to the ingress and egress node along the setup of SHOULD be reported to the ingress and egress node along the setup of
the LSP. the LSP.
The rules for the processing of the Attribute Flags TLV are not The rules for the processing of the Attribute Flags TLV are not
changed. changed.
skipping to change at page 7, line 36 skipping to change at page 7, line 40
This field contains one SRLG ID. There is one SRLG ID field per SRLG This field contains one SRLG ID. There is one SRLG ID field per SRLG
collected. There MAY be multiple SRLG ID fields in an SRLG sub- collected. There MAY be multiple SRLG ID fields in an SRLG sub-
object. object.
A node MUST NOT push a SRLG sub-object in the RECORD_ROUTE without A node MUST NOT push a SRLG sub-object in the RECORD_ROUTE without
also pushing either a IPv4 sub-object, a IPv6 sub-object, a also pushing either a IPv4 sub-object, a IPv6 sub-object, a
Unnumbered Interface ID sub-object or a Path Key sub-object. Unnumbered Interface ID sub-object or a Path Key sub-object.
As described in RFC 3209 [RFC3209], the RECORD_ROUTE object is As described in RFC 3209 [RFC3209], the RECORD_ROUTE object is
managed as a stack. The SRLG sub-object SHOULD be pushed by the node managed as a stack. The SRLG sub-object MUST be pushed by the node
before the node IP address or link identifier. The SRLG-sub-object before the node IP address or link identifier. The SRLG-sub-object
SHOULD be pushed after the Attribute sub-object, if present, and SHOULD be pushed after the Attribute sub-object, if present, and
after the LABEL sub-object, if requested. It MUST be pushed within after the LABEL sub-object, if requested. It MUST be pushed within
the hop to which it applies. the hop to which it applies.
RFC 5553 [RFC5553] describes mechanisms to carry a PKS (Path Key Sub- RFC 5553 [RFC5553] describes mechanisms to carry a PKS (Path Key Sub-
object) in the RRO so as to facilitate confidentiality in the object) in the RRO so as to facilitate confidentiality in the
signaling of inter-domain TE LSPs, and allows the path segment that signaling of inter-domain TE LSPs, and allows the path segment that
needs to be hidden (that is, a Confidential Path Segment (CPS)) to be needs to be hidden (that is, a Confidential Path Segment (CPS)) to be
replaced in the RRO with a PKS. If the CPS contains SRLG Sub- replaced in the RRO with a PKS. If the CPS contains SRLG Sub-
skipping to change at page 8, line 21 skipping to change at page 8, line 26
5.1. SRLG Collection 5.1. SRLG Collection
Per RFC 3209 [RFC3209], an ingress node initiates the recording of Per RFC 3209 [RFC3209], an ingress node initiates the recording of
the route information of an LSP by adding a RRO to a Path message. If the route information of an LSP by adding a RRO to a Path message. If
an ingress node also desires SRLG recording, it MUST set the SRLG an ingress node also desires SRLG recording, it MUST set the SRLG
Collection Flag in the Attribute Flags TLV which MAY be carried Collection Flag in the Attribute Flags TLV which MAY be carried
either in an LSP_REQUIRED_ATTRIBUTES Object when the collection is either in an LSP_REQUIRED_ATTRIBUTES Object when the collection is
mandatory, or in an LSP_ATTRIBUTES Object when the collection is mandatory, or in an LSP_ATTRIBUTES Object when the collection is
desired, but not mandatory. desired, but not mandatory.
A node SHOULD NOT add SRLG information without an explicit request A node MUST NOT add SRLG information without an explicit request for
for it being made by the ingress node in the Path message. it being made by the ingress node in the Path message.
When a node receives a Path message which carries an When a node receives a Path message which carries an
LSP_REQUIRED_ATTRIBUTES Object with the SRLG Collection Flag set, if LSP_REQUIRED_ATTRIBUTES Object with the SRLG Collection Flag set, if
local policy determines that the SRLG information is not to be local policy determines that the SRLG information is not to be
provided to the endpoints, it MUST return a PathErr message with: provided to the endpoints, it MUST return a PathErr message with:
o Error Code 2 (policy) and o Error Code 2 (policy) and
o Error subcode "SRLG Recording Rejected" (see Section 8.3 for o Error subcode "SRLG Recording Rejected" (see Section 8.3 for
value) value)
to reject the Path message. to reject the Path message.
When a node receives a Path message which carries an LSP_ATTRIBUTES When a node receives a Path message which carries an LSP_ATTRIBUTES
Object with the SRLG Collection Flag set, if local policy determines Object with the SRLG Collection Flag set, if local policy determines
that the SRLG information is not to be provided to the endpoints, the that the SRLG information is not to be provided to the endpoints, the
Path message SHOULD NOT be rejected due to the SRLG recording Path message MUST NOT be rejected due to the SRLG recording
restriction and the Path message SHOULD be forwarded without any SRLG restriction and the Path message MUST be forwarded without any SRLG
sub-object(s) added to the RRO of the corresponding outgoing Path sub-object(s) added to the RRO of the corresponding outgoing Path
message. message.
If local policy permits the recording of the SRLG information, the If local policy permits the recording of the SRLG information, the
processing node SHOULD add local SRLG information, as defined below, processing node SHOULD add local SRLG information, as defined below,
to the RRO of the corresponding outgoing Path message. The to the RRO of the corresponding outgoing Path message. The
processing node MAY add multiple SRLG sub-objects to the RRO if processing node MAY add multiple SRLG sub-objects to the RRO if
necessary. It then forwards the Path message to the next node in the necessary. It then forwards the Path message to the next node in the
downstream direction. The processing node MUST retain a record of the downstream direction. The processing node MUST retain a record of the
SRLG recording request for reference during Resv processing described SRLG recording request for reference during Resv processing described
skipping to change at page 9, line 11 skipping to change at page 9, line 17
If the addition of SRLG information to the RRO would result in the If the addition of SRLG information to the RRO would result in the
RRO exceeding its maximum possible size or becoming too large for the RRO exceeding its maximum possible size or becoming too large for the
Path message to contain it, the requested SRLGs MUST NOT be added. If Path message to contain it, the requested SRLGs MUST NOT be added. If
the SRLG collection request was contained in an the SRLG collection request was contained in an
LSP_REQUIRED_ATTRIBUTES Object, the processing node MUST behave as LSP_REQUIRED_ATTRIBUTES Object, the processing node MUST behave as
specified by RFC 3209 [RFC3209] and drop the RRO from the Path specified by RFC 3209 [RFC3209] and drop the RRO from the Path
message entirely. If the SRLG collection request was contained in an message entirely. If the SRLG collection request was contained in an
LSP_ATTRIBUTES Object, the processing node MAY omit some or all of LSP_ATTRIBUTES Object, the processing node MAY omit some or all of
the requested SRLGs from the RRO; otherwise it MUST behave as the requested SRLGs from the RRO; otherwise it MUST behave as
specified by [RFC3209] and drop the RRO from the Path message specified by [RFC3209] and drop the RRO from the Path message
entirely. entirely. Subsequent processing of the LSP proceeds as further
specified in RFC 3209 [RFC3209].
Following the steps described above, the intermediate nodes of the Following the steps described above, the intermediate nodes of the
LSP can collect the SRLG information in the RRO during the processing LSP can collect the SRLG information in the RRO during the processing
of the Path message hop by hop. When the Path message arrives at the of the Path message hop by hop. When the Path message arrives at the
egress node, the egress node receives SRLG information in the RRO. egress node, the egress node receives SRLG information in the RRO.
Per RFC 3209 [RFC3209], when issuing a Resv message for a Path Per RFC 3209 [RFC3209], when issuing a Resv message for a Path
message which contains an RRO, an egress node initiates the RRO message which contains an RRO, an egress node initiates the RRO
process by adding an RRO to the outgoing Resv message. The process by adding an RRO to the outgoing Resv message. The
processing for RROs contained in Resv messages then mirrors that of processing for RROs contained in Resv messages then mirrors that of
skipping to change at page 10, line 21 skipping to change at page 10, line 28
of the Forwarding Adjacency (FA) automatically. of the Forwarding Adjacency (FA) automatically.
5.2. SRLG Update 5.2. SRLG Update
When the SRLG information of a link is changed, the endpoints of LSPs When the SRLG information of a link is changed, the endpoints of LSPs
using that link need to be made aware of the changes. When a change using that link need to be made aware of the changes. When a change
to the set of SRLGs associated with a link occurs, the procedures to the set of SRLGs associated with a link occurs, the procedures
defined in Section 4.4.3 of RFC 3209 [RFC3209] MUST be used to defined in Section 4.4.3 of RFC 3209 [RFC3209] MUST be used to
refresh the SRLG information for each affected LSP if the SRLG change refresh the SRLG information for each affected LSP if the SRLG change
is to be communicated to other nodes according to the local node's is to be communicated to other nodes according to the local node's
policy. If local policy is that the SRLG change SHOULD be suppressed policy.
or would result in no change to the previously signaled SRLG-list,
the node SHOULD NOT send an update.
5.3 Domain Boundaries 5.3 Domain Boundaries
If mandated by local policy, a node MAY remove SRLG information from If mandated by local policy as specified by the network operator, a
any RRO in a Path or Resv message being processed. It MAY add a node MAY remove SRLG information from any RRO in a Path or Resv
summary of the removed SRLGs or map them to other SRLG values. message being processed. It MAY add a summary of the removed SRLGs or
However, this SHOULD NOT be done unless explicitly mandated by local map them to other SRLG values. However, this SHOULD NOT be done
policy. unless explicitly mandated by local policy.
5.4. Compatibility 5.4. Compatibility
A node that does not recognize the SRLG Collection Flag in the A node that does not recognize the SRLG Collection Flag in the
Attribute Flags TLV is expected to proceed as specified in RFC 5420 Attribute Flags TLV is expected to proceed as specified in RFC 5420
[RFC5420]. It is expected to pass the TLV on unaltered if it appears [RFC5420]. It is expected to pass the TLV on unaltered if it appears
in a LSP_ATTRIBUTES object, or reject the Path message with the in a LSP_ATTRIBUTES object, or reject the Path message with the
appropriate Error Code and Value if it appears in a appropriate Error Code and Value if it appears in a
LSP_REQUIRED_ATTRIBUTES object. LSP_REQUIRED_ATTRIBUTES object.
skipping to change at page 10, line 47 skipping to change at page 11, line 4
[RFC5420]. It is expected to pass the TLV on unaltered if it appears [RFC5420]. It is expected to pass the TLV on unaltered if it appears
in a LSP_ATTRIBUTES object, or reject the Path message with the in a LSP_ATTRIBUTES object, or reject the Path message with the
appropriate Error Code and Value if it appears in a appropriate Error Code and Value if it appears in a
LSP_REQUIRED_ATTRIBUTES object. LSP_REQUIRED_ATTRIBUTES object.
A node that does not recognize the SRLG RRO sub-object is expected to A node that does not recognize the SRLG RRO sub-object is expected to
behave as specified in RFC 3209 [RFC3209]: unrecognized sub-objects behave as specified in RFC 3209 [RFC3209]: unrecognized sub-objects
are to be ignored and passed on unchanged. are to be ignored and passed on unchanged.
6. Manageability Considerations 6. Manageability Considerations
6.1. Policy Configuration 6.1. Policy Configuration
In a border node of inter-domain or inter-layer network, the In a border node of inter-domain or inter-layer network, the
following SRLG processing policy MUST be capable of being configured: following SRLG processing policy MUST be capable of being configured:
o Whether the node is allowed to participate in SRLG collection. o Whether the node is allowed to participate in SRLG collection and
notify changes to collected SRLG information to endpoint nodes as
o Whether the node should notify changes to collected SRLG described in section 5.2.
information to endpoint nodes as described in section 5.2.
o Whether the SRLG IDs of the domain or specific layer network can o Whether the SRLG IDs of the domain or specific layer network can
be exposed to the nodes outside the domain or layer network, or be exposed to the nodes outside the domain or layer network, or
whether they SHOULD be summarized, mapped to values that are whether they SHOULD be summarized, mapped to values that are
comprehensible to nodes outside the domain or layer network, or comprehensible to nodes outside the domain or layer network, or
removed entirely as described in section 5.3. removed entirely as described in section 5.3.
A node using RFC 5553 [RFC5553] and PKS MAY apply the same policy. A node using RFC 5553 [RFC5553] and PKS MAY apply the same policy.
6.2. Coherent SRLG IDs 6.2. Coherent SRLG IDs
skipping to change at page 11, line 49 skipping to change at page 12, line 4
mechanisms for the GMPLS control plane. The procedures defined in mechanisms for the GMPLS control plane. The procedures defined in
this document permit the transfer of SRLG data between layers or this document permit the transfer of SRLG data between layers or
domains during the signaling of LSPs, subject to policy at the layer domains during the signaling of LSPs, subject to policy at the layer
or domain boundary. It is recommended that domain/layer boundary or domain boundary. It is recommended that domain/layer boundary
policies take the implications of releasing SRLG information into policies take the implications of releasing SRLG information into
consideration and behave accordingly during LSP signaling. consideration and behave accordingly during LSP signaling.
8. IANA Considerations 8. IANA Considerations
8.1. RSVP Attribute Bit Flags 8.1. RSVP Attribute Bit Flags
IANA has created a registry and manages the space of the Attribute IANA has created a registry and manages the space of the Attribute
bit flags of the Attribute Flags TLV, as described in section 11.3 of bit flags of the Attribute Flags TLV, as described in section 11.3 of
RFC 5420 [RFC5420], in the "Attribute Flags" section of the "Resource RFC 5420 [RFC5420], in the "Attribute Flags" section of the "Resource
Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters"
registry located in http://www.iana.org/assignments/rsvp-te- registry located in http://www.iana.org/assignments/rsvp-te-
parameters". parameters".
This document introduces a new Attribute Bit Flag: This document introduces a new Attribute Bit Flag:
Bit No Name Attribute Attribute RRO Reference Bit No Name Attribute Attribute ERO RRO Reference
Flags Path Flags Resv Flags Path Flags Resv
-------------- ---------- ---------- ----------- --- --------- --------- ---------- ---------- ----------- --- --- ---------
TBD; suggested SRLG Yes No Yes This I-D TBD; SRLG Yes No No Yes This I-D
value: 12 Flag suggested Collection
value: 12 Flag
8.2. ROUTE_RECORD Object 8.2. ROUTE_RECORD Object
IANA manages the "RSVP PARAMETERS" registry located at IANA manages the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters. This document http://www.iana.org/assignments/rsvp-parameters. This document
introduces a new RRO sub-object: introduces a new RRO sub-object:
Value Description Reference Value Description Reference
--------------------- ------------------- --------- --------------------- ------------------- ---------
TBD; suggested SRLG sub-object This I-D TBD; suggested SRLG sub-object This I-D
 End of changes. 16 change blocks. 
32 lines changed or deleted 33 lines changed or added

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