draft-ietf-teas-rsvp-te-srlg-collect-01.txt   draft-ietf-teas-rsvp-te-srlg-collect-02.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: December 14, 2015 Telefonica Global CTO Expires: December 25, 2015 Telefonica Global CTO
D. Li
Huawei
C. Margaria
M. Hartley M. Hartley
Z. Ali Z. Ali
Cisco Cisco
C. Margaria
June 12, 2015 June 25, 2015
RSVP-TE Extensions for Collecting SRLG Information RSVP-TE Extensions for Collecting SRLG Information
draft-ietf-teas-rsvp-te-srlg-collect-01 draft-ietf-teas-rsvp-te-srlg-collect-02
Abstract Abstract
This document provides extensions for the Resource ReserVation This document provides extensions for the Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) to support automatic Protocol-Traffic Engineering (RSVP-TE) to support automatic
collection of Shared Risk Link Group (SRLG) information for the TE collection of Shared Risk Link Group (SRLG) information for the TE
link formed by a Label Switched Path (LSP). link formed by a Label Switched Path (LSP).
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 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 14, 2015. This Internet-Draft will expire on December 25, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 22 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . . 5
4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . 5 4.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . 5
4.2. SRLG sub-object . . . . . . . . . . . . . . . . . . . . . 6 4.2. RRO SRLG sub-object . . . . . . . . . . . . . . . . . . . 6
5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . 7 5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . 7
5.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 7 5.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 7
5.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Compatibility . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Compatibility . . . . . . . . . . . . . . . . . . . . . . 9
6. Manageability Considerations . . . . . . . . . . . . . . . . 9 6. Manageability Considerations . . . . . . . . . . . . . . . . 9
6.1. Policy Configuration . . . . . . . . . . . . . . . . . . 9 6.1. Policy Configuration . . . . . . . . . . . . . . . . . . 9
6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 9 6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . 10 8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . 10
8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 11 8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 11
8.3. Policy Control Failure Error subcodes . . . . . . . . . . 11 8.3. Policy Control Failure Error subcodes . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
It is important to understand which TE links in the network might be It is important to understand which TE links in the network might be
at risk from the same failures. In this sense, a set of links can at risk from the same failures. In this sense, a set of links can
constitute a 'shared risk link group' (SRLG) if they share a resource constitute a 'shared risk link group' (SRLG) if they share a resource
whose failure can affect all links in the set [RFC4202]. whose failure can affect all links in the set [RFC4202].
On the other hand, as described in [RFC4206] and [RFC6107], H-LSP On the other hand, as described in [RFC4206] and [RFC6107], H-LSP
skipping to change at page 6, line 5 skipping to change at page 6, line 5
IANA, see Section 8.1 for more details): SRLG Collection flag IANA, see Section 8.1 for more details): 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 of the processing of the Attribute Flags TLV are not The rules of the processing of the Attribute Flags TLV are not
changed. changed.
4.2. SRLG sub-object 4.2. RRO SRLG sub-object
This document defines a new RRO sub-object (ROUTE_RECORD sub-object) This document defines a new RRO sub-object (ROUTE_RECORD sub-object)
to record the SRLG information of the LSP. Its format is modeled on to record the SRLG information of the LSP. Its format is modeled on
the RRO sub-objects defined in RFC 3209 [RFC3209]. the RRO sub-objects defined in RFC 3209 [RFC3209].
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 | Length | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 28 skipping to change at page 7, line 28
5. Signaling Procedures 5. Signaling Procedures
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.
When a node receives a Path message which carries an When a node receives a Path message which carries an
LSP_REQUIRED_ATTRIBUTES Object and the SRLG Collection Flag set, if LSP_REQUIRED_ATTRIBUTES Object and 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:
Error Code 2 (policy) and Error subcode "SRLG Recording Rejected" o Error Code 2 (policy) and
(value 31, an early allocation of the value has been done by IANA, o Error subcode "SRLG Recording Rejected" (value 31, an early
see Section 8.3 for more details) to reject the Path message. allocation of the value has been done by IANA, see Section 8.3 for
more details)
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 and the SRLG Collection Flag set, if local policy determines Object and 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 SRLG recording restriction Path message SHOULD NOT be rejected due to SRLG recording restriction
and the Path message SHOULD be forwarded without any SRLG sub- and the Path message SHOULD be forwarded without any SRLG sub-
object(s) in the RRO of the corresponding outgoing Path message. object(s) in the RRO of the corresponding outgoing Path 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,
skipping to change at page 11, line 36 skipping to change at page 11, line 36
Error Value Sub-Codes" section of the "RSVP PARAMETERS" registry. The Error Value Sub-Codes" section of the "RSVP PARAMETERS" registry. The
early allocation expires on 2015-09-11. early allocation expires on 2015-09-11.
This document introduces a new Policy Control Failure Error sub-code: This document introduces a new Policy Control Failure Error sub-code:
Value Description Reference Value Description Reference
--------------------- ----------------------- --------- --------------------- ----------------------- ---------
21 (temporary, SRLG Recording Rejected This I-D 21 (temporary, SRLG Recording Rejected This I-D
expires 2015-09-11) expires 2015-09-11)
9. Acknowledgements 9. Contributors
Dan Li
Huawei
F3-5-B RD Center
Bantian, Longgang District, Shenzhen 518129
P.R.China
Email: danli@huawei.com
10. Acknowledgements
The authors would like to thank Igor Bryskin, Ramon Casellas, Lou The authors would like to thank Igor Bryskin, Ramon Casellas, Lou
Berger, Alan Davey, Dhruv Dhody and Dieter Beller for their useful Berger, Alan Davey, Dhruv Dhody and Dieter Beller for their useful
comments and improvements to the document. comments and improvements to this document.
10. References
10.1. Normative References 11. 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
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
skipping to change at page 12, line 22 skipping to change at page 12, line 30
Engineering (RSVP-TE)", RFC 5420, February 2009. Engineering (RSVP-TE)", RFC 5420, February 2009.
[RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving
Topology Confidentiality in Inter-Domain Path Computation Topology Confidentiality in Inter-Domain Path Computation
Using a Path-Key-Based Mechanism", RFC 5520, April 2009. Using a Path-Key-Based Mechanism", RFC 5520, April 2009.
[RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource [RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource
Reservation Protocol (RSVP) Extensions for Path Key Reservation Protocol (RSVP) Extensions for Path Key
Support", RFC 5553, May 2009. Support", RFC 5553, May 2009.
10.2. Informative References 11.2. Informative References
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005. (GMPLS)", RFC 4202, October 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
skipping to change at page 13, line 19 skipping to change at page 14, line 19
Email: zhangfatai@huawei.com Email: zhangfatai@huawei.com
Oscar Gonzalez de Dios (editor) Oscar Gonzalez de Dios (editor)
Telefonica Global CTO Telefonica Global CTO
Distrito Telefonica, edificio sur, Ronda de la Comunicacion 28045 Distrito Telefonica, edificio sur, Ronda de la Comunicacion 28045
Madrid 28050 Madrid 28050
Spain Spain
Phone: +34 913129647 Phone: +34 913129647
Email: oscar.gonzalezdedios@telefonica.com Email: oscar.gonzalezdedios@telefonica.com
Dan Li
Huawei
F3-5-B RD Center
Bantian, Longgang District, Shenzhen 518129
P.R.China
Email: danli@huawei.com
Cyril Margaria Cyril Margaria
Suite 4001, 200 Somerset Corporate Blvd. Suite 4001, 200 Somerset Corporate Blvd.
Bridgewater, NJ 08807 Bridgewater, NJ 08807
US US
Email: cyril.margaria@gmail.com Email: cyril.margaria@gmail.com
Matt Hartley Matt Hartley
Cisco Cisco
Email: mhartley@cisco.com Email: mhartley@cisco.com
 End of changes. 16 change blocks. 
32 lines changed or deleted 34 lines changed or added

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