draft-ietf-teas-rsvp-te-srlg-collect-00.txt   draft-ietf-teas-rsvp-te-srlg-collect-01.txt 
Network 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: June 14, 2015 Telefonica Global CTO Expires: December 14, 2015 Telefonica Global CTO
D. Li D. Li
Huawei Huawei
C. Margaria C. Margaria
M. Hartley M. Hartley
Z. Ali Z. Ali
Cisco Cisco
December 11, 2014
June 12, 2015
RSVP-TE Extensions for Collecting SRLG Information RSVP-TE Extensions for Collecting SRLG Information
draft-ietf-teas-rsvp-te-srlg-collect-00 draft-ietf-teas-rsvp-te-srlg-collect-01
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 41
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 June 14, 2015. This Internet-Draft will expire on December 14, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 3, line 43 skipping to change at page 3, line 42
+-----+ +-----+ +-----+ +-----+
\ / \ /
+---+ +---+ +---+ +---+
| P |....| P | | P |....| P |
+---+ +---+ +---+ +---+
Figure 1: Dual Homing Configuration Figure 1: Dual Homing Configuration
Single-homed customer edge (CE) devices are connected to a single Single-homed customer edge (CE) devices are connected to a single
provider edge (PE) device via a single UNI link (which could be a provider edge (PE) device via a single UNI link (which could be a
bundle of parallel links, typically using the same fiber cable). bundle of parallel links, typically using the same fiber cable). This
This single UNI link can constitute a single point of failure. Such single UNI link can constitute a single point of failure. Such a
a single point of failure can be avoided if the CE device is single point of failure can be avoided if the CE device is connected
connected to two PE devices via two UNI interfaces as depicted in to two PE devices via two UNI interfaces as depicted in Figure 1
Figure 1 above for CE1 and CE2, respectively. above for CE1 and CE2, respectively.
For the dual-homing case, it is possible to establish two connections For the dual-homing case, it is possible to establish two connections
(LSPs) from the source CE device to the same destination CE device (LSPs) from the source CE device to the same destination CE device
where one connection is using one UNI link to PE1, for example, and where one connection is using one UNI link to PE1, for example, and
the other connection is using the UNI link to PE2. In order to avoid the other connection is using the UNI link to PE2. In order to avoid
single points of failure within the provider network, it is necessary single points of failure within the provider network, it is necessary
to also ensure path (LSP) diversity within the provider network in to also ensure path (LSP) diversity within the provider network in
order to achieve end-to-end diversity for the two LSPs between the order to achieve end-to-end diversity for the two LSPs between the
two CE devices CE1 and CE2. This use case describes how it is two CE devices CE1 and CE2. This use case describes how it is
possible to achieve path diversity within the provider network based possible to achieve path diversity within the provider network based
skipping to change at page 7, line 23 skipping to change at page 7, line 23
Unnumbered Interface ID sub-object or a Path Key sub-object. Unnumbered Interface ID sub-object or a Path Key sub-object.
The rules of the processing of the LSP_REQUIRED_ATTRIBUTES, The rules of the processing of the LSP_REQUIRED_ATTRIBUTES,
LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed. LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed.
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. the route information of an LSP by adding a RRO to a Path message. If
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" Error Code 2 (policy) and Error subcode "SRLG Recording Rejected"
skipping to change at page 8, line 7 skipping to change at page 8, line 7
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
necesary. It then forwards the Path message to the next node in the necesary. It then forwards the Path message to the next node in the
downstream direction. downstream direction.
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. Path message to contain it, the requested SRLGs MUST NOT be added. If
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 RFC 3209 [RFC3209] and drop the RRO from the Path specified by RFC 3209 [RFC3209] and drop the RRO from the Path
message entirely. message entirely.
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
skipping to change at page 11, line 26 skipping to change at page 11, line 26
34 (temporary, SRLG sub-object This I-D 34 (temporary, SRLG sub-object This I-D
expires 2015-09-11) expires 2015-09-11)
8.3. Policy Control Failure Error subcodes 8.3. Policy Control Failure Error subcodes
IANA manages the assignments in the "Error Codes and Globally-Defined IANA manages the assignments in the "Error Codes and Globally-Defined
Error Value Sub-Codes" section of the "RSVP PARAMETERS" registry Error Value Sub-Codes" section of the "RSVP PARAMETERS" registry
located at http://www.iana.org/assignments/rsvp-parameters. IANA has located at http://www.iana.org/assignments/rsvp-parameters. IANA has
made an early allocation in the "Sub-Codes - 2 Policy Control made an early allocation in the "Sub-Codes - 2 Policy Control
Failure" subsection of the the "Error Codes and Globally-Defined Failure" subsection of the the "Error Codes and Globally-Defined
Error Value Sub-Codes" section of the "RSVP PARAMETERS" registry. Error Value Sub-Codes" section of the "RSVP PARAMETERS" registry. The
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. Acknowledgements
 End of changes. 10 change blocks. 
17 lines changed or deleted 17 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/