draft-ietf-teas-rsvp-te-srlg-collect-03.txt   draft-ietf-teas-rsvp-te-srlg-collect-04.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 August 14, 2016 Telefonica Global CTO Expires September 15, 2016 Telefonica Global CTO
M. Hartley M. Hartley
Z. Ali Z. Ali
Cisco Cisco
C. Margaria C. Margaria
February 11, 2016 March 15, 2016
RSVP-TE Extensions for Collecting SRLG Information RSVP-TE Extensions for Collecting SRLG Information
draft-ietf-teas-rsvp-te-srlg-collect-03 draft-ietf-teas-rsvp-te-srlg-collect-04
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 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 25, 2015. This Internet-Draft will expire on September 15, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Applicability Example: Dual Homing . . . . . . . . . . . 3 1.1. Applicability Example: Dual Homing . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. RSVP-TE Requirements . . . . . . . . . . . . . . . . . . . . 5 3. RSVP-TE Requirements . . . . . . . . . . . . . . . . . . . . 5
3.1. SRLG Collection Indication . . . . . . . . . . . . . . . 5 3.1. SRLG Collection Indication . . . . . . . . . . . . . . . 5
3.2. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 5 3.2. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 5
3.3. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . . . 12
8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . 11 8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . . 13 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
skipping to change at page 4, line 49 skipping to change at page 4, line 49
When CE1 sends the setup request for LSP2 to PE2, it can also request When CE1 sends the setup request for LSP2 to PE2, it can also request
the collection of SRLG information for LSP2 and send that information the collection of SRLG information for LSP2 and send that information
to PE1 by re-signaling LSP1 with SRLG-exclusion based on LSP2's to PE1 by re-signaling LSP1 with SRLG-exclusion based on LSP2's
discovered SRLGs. This will ensure that the two paths for the two discovered SRLGs. This will ensure that the two paths for the two
LSPs remain mutually diverse, which is important when the provider LSPs remain mutually diverse, which is important when the provider
network is capable of restoring connections that failed due to a network is capable of restoring connections that failed due to a
network failure (fiber cut) in the provider network. network failure (fiber cut) in the provider network.
Note that the knowledge of SRLG information even for multiple LSPs Note that the knowledge of SRLG information even for multiple LSPs
does not allow a CE device to derive the provider network topology does not allow a CE device to derive the provider network topology
based on the collected SRLG information. based on the collected SRLG information. It would, however, be
possible for an entity controlling multiple CE devices to derive some
information related to the topology. This document therefore allows
PE devices to control the communication of SRLGs outside the provider
network if desired.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. RSVP-TE Requirements 3. RSVP-TE Requirements
The SRLG-collection process takes place in three stages: The SRLG-collection process takes place in three stages:
o The LSP's ingress node requests that SRLG collection take place; o The LSP's ingress node requests that SRLG collection take place;
skipping to change at page 9, line 26 skipping to change at page 9, line 32
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
the Path messages. the Path messages.
When a node receives a Resv message for an LSP for which SRLG When a node receives a Resv message for an LSP for which SRLG
Collection was specified in the corresponding Path message, then when Collection was specified in the corresponding Path message, then when
local policy allows recording SRLG information, the node SHOULD add local policy allows recording SRLG information, the node MUST add
SRLG information to the RRO of the corresponding outgoing Resv SRLG information to the RRO of the corresponding outgoing Resv
message as specified below. When the Resv message arrives at the message as specified below. When the Resv message arrives at the
ingress node, the ingress node can extract the SRLG information from ingress node, the ingress node can extract the SRLG information from
the RRO in the same way as the egress node. the RRO in the same way as the egress node.
Note that a link's SRLG information for the upstream direction cannot Note that a link's SRLG information for the upstream direction cannot
be assumed to be the same as that in the downstream. be assumed to be the same as that in the downstream.
o For Path and Resv messages for a unidirectional LSP, a node SHOULD o For Path and Resv messages for a unidirectional LSP, a node SHOULD
include SRLG sub-objects in the RRO for the downstream data link include SRLG sub-objects in the RRO for the downstream data link
skipping to change at page 11, line 4 skipping to change at page 11, line 9
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 SHOULD be capable of being following SRLG processing policy MUST be capable of being configured:
configured:
o Whether the node is allowed to participate in SRLG collection. o o Whether the node is allowed to participate in SRLG collection. o
Whether the node should notify changes to collected SRLG Whether the node should notify changes to collected SRLG
information to endpoint nodes as described in section 5.2. o information to endpoint nodes as described in section 5.2. o
Whether the SRLG IDs of the domain or specific layer network can 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.
skipping to change at page 13, line 7 skipping to change at page 13, line 12
Dan Li Dan Li
Huawei Huawei
F3-5-B RD Center F3-5-B RD Center
Bantian, Longgang District, Shenzhen 518129 Bantian, Longgang District, Shenzhen 518129
P.R.China P.R.China
Email: danli@huawei.com Email: danli@huawei.com
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Igor Bryskin, Ramon Casellas, Lou The authors would like to thank Dieter Beller, Lou Berger, Igor
Berger, Alan Davey, Elwyn Davies, Dhruv Dhody and Dieter Beller for Bryskin, Ramon Casellas, Niclas Comstedt, Alan Davey, Elwyn Davies
their useful comments and improvements to this document. and Dhruv Dhody for their useful comments and improvements to this
document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
 End of changes. 14 change blocks. 
17 lines changed or deleted 23 lines changed or added

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