draft-ietf-teas-lsp-diversity-02.txt   draft-ietf-teas-lsp-diversity-03.txt 
TEAS Working Group Zafar Ali, Ed. TEAS Working Group Zafar Ali, Ed.
Internet Draft George Swallow, Ed. Internet Draft George Swallow, Ed.
Intended status: Standard Track Cisco Systems Intended status: Standard Track Cisco Systems
Expires: January 7, 2016 F. Zhang, Ed. Expires: July 8, 2016 F. Zhang, Ed.
Huawei Huawei
D. Beller, Ed. D. Beller, Ed.
Alcatel-Lucent Alcatel-Lucent
July 6, 2015 January 5, 2016
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path
Diversity using Exclude Route Diversity using Exclude Route
draft-ietf-teas-lsp-diversity-02.txt draft-ietf-teas-lsp-diversity-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2015. This Internet-Draft will expire on July 8, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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 carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
skipping to change at page 2, line 23 skipping to change at page 2, line 23
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction..................................................2 1. Introduction..................................................2
1.1. Client-Initiated Identifier...........................5 1.1. Client-Initiated Identifier...........................5
1.2. PCE-allocated Identifier..............................6 1.2. PCE-allocated Identifier..............................6
1.3. Network-Assigned Identifier...........................7 1.3. Network-Assigned Identifier...........................7
2. RSVP-TE signaling extensions..................................9 2. RSVP-TE signaling extensions..................................9
2.1. Diversity XRO Subobject...............................9 2.1. Diversity XRO Subobject...............................9
2.1.1. IPv4 Diversity XRO Subobject............................. 9 2.1.1. IPv4 Diversity XRO Subobject................. 9
2.1.2. IPv6 Diversity XRO Subobject............................ 13 2.1.2. IPv6 Diversity XRO Subobject................ 13
2.2. Processing rules for the Diversity XRO subobject.....17 2.2. Processing rules for the Diversity XRO subobject.....17
2.3. Diversity EXRS Subobject.............................20 2.3. Diversity EXRS Subobject.............................20
3. Security Considerations......................................22 3. Security Considerations......................................22
4. IANA Considerations..........................................22 4. IANA Considerations..........................................22
4.1. New XRO subobject types..............................22 4.1. New XRO subobject types..............................22
4.2. New EXRS subobject types.............................22 4.2. New EXRS subobject types.............................22
4.3. New RSVP error sub-codes.............................22 4.3. New RSVP error sub-codes.............................22
5. Acknowledgements.............................................23 5. Acknowledgements.............................................23
6. References...................................................23 6. References...................................................23
6.1. Normative References.................................23 6.1. Normative References.................................23
skipping to change at page 4, line 25 skipping to change at page 4, line 25
+---------+ | | +--+--+ | +--+--+ | | +---------+ +---------+ | | +--+--+ | +--+--+ | | +---------+
| +----+ | | | | | +-------+ +-----+ | +----+ | | +----+ | | | | | +-------+ +-----+ | +----+ |
| | +-+--+ | | CN4 +---------------+ CN5 | | | | | | | | +-+--+ | | CN4 +---------------+ CN5 | | | | | |
| -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- | | -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- |
| | | | UNI | +-----+ +-----+ | UNI | | | | | | | | UNI | +-----+ +-----+ | UNI | | | |
| +----+ | | | | +----+ | | +----+ | | | | +----+ |
+---------+ +----------------------------------+ +---------+ +---------+ +----------------------------------+ +---------+
Overlay Core Network Overlay Overlay Core Network Overlay
Network Network Network Network
Legend: EN - Edge Node Legend: EN - Edge Node
CN - Core Node CN - Core Node
Figure 1: Overlay Reference Model [RFC4208] Figure 1: Overlay Reference Model [RFC4208]
Figure 1 depicts two types of UNI connectivity: single-homed and Figure 1 depicts two types of UNI connectivity: single-homed and
dual-homed ENs (which also applies to higher order multi-homed dual-homed ENs (which also applies to higher order multi-homed
connectivity.). Single-homed EN devices are connected to a single connectivity.). Single-homed EN devices are connected to a single
CN device via a single UNI link. This single UNI link may CN device via a single UNI link. This single UNI link may
constitute a single point of failure. UNI connection between EN1 constitute a single point of failure. UNI connection between EN1
and CN1 is an example of singled-homed UNI connectivity. and CN1 is an example of singled-homed UNI connectivity.
skipping to change at page 5, line 22 skipping to change at page 5, line 22
LSP from EN2 to EN3 traversing CN1 needs to be diverse from an LSP from EN2 to EN3 traversing CN1 needs to be diverse from an
LSP from EN2 to EN3 going via CN4. Again in this case, exclusions LSP from EN2 to EN3 going via CN4. Again in this case, exclusions
based on [RFC4874] cannot be used. based on [RFC4874] cannot be used.
This document addresses these diversity requirements by This document addresses these diversity requirements by
introducing the notion of excluding the path taken by particular introducing the notion of excluding the path taken by particular
LSP(s). The reference LSP(s) or route(s) from which diversity is LSP(s). The reference LSP(s) or route(s) from which diversity is
required is/are identified by an "identifier". The type of required is/are identified by an "identifier". The type of
identifier to use is highly dependent on the networking identifier to use is highly dependent on the networking
deployment scenario; it could be client-initiated, allocated by deployment scenario; it could be client-initiated, allocated by
the (core) network or managed by a PCE . This document defines the (core) network or managed by a PCE. This document defines
three different types of identifiers corresponding to these three three different types of identifiers corresponding to these three
cases: a client initiated identifier, a PCE allocated Identifier cases: a client initiated identifier, a PCE allocated Identifier
and CN ingress node (UNI-N) allocated Identifier. and CN ingress node (UNI-N) allocated Identifier.
1.1. Client-Initiated Identifier 1.1. Client-Initiated Identifier
There are scenarios in which the ENs have the following There are scenarios in which the ENs have the following
requirements for the diversity identifier: requirements for the diversity identifier:
- The identifier is controlled by the client side and is - The identifier is controlled by the client side and is
skipping to change at page 24, line 29 skipping to change at page 24, line 29
MPLS and GMPLS RSVP-TE", RFC 4920, July 2007. MPLS and GMPLS RSVP-TE", RFC 4920, July 2007.
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
"Preserving Topology Confidentiality in Inter-Domain "Preserving Topology Confidentiality in Inter-Domain
Path Computation Using a Path-Key-Based Mechanism", RFC Path Computation Using a Path-Key-Based Mechanism", RFC
5520, April 2009. 5520, April 2009.
[DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C. [DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C.
Margaria, "RSVP-TE Extensions for Collecting SRLG Margaria, "RSVP-TE Extensions for Collecting SRLG
Information", draft-ietf-teas-rsvp-te-srlg-collect-02, Information", draft-ietf-teas-rsvp-te-srlg-collect-02,
work in progress. in expert review.
[RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and
S. Jamin, "Resource ReserVation Protocol -- Version 1 S. Jamin, "Resource ReserVation Protocol -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned
Virtual Private Network (VPN) Terminology", RFC 4026, Virtual Private Network (VPN) Terminology", RFC 4026,
March 2005. March 2005.
[RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1 [RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1
skipping to change at page 25, line 17 skipping to change at page 25, line 17
Igor Bryskin Igor Bryskin
ADVA Optical Networking ADVA Optical Networking
Email: ibryskin@advaoptical.com Email: ibryskin@advaoptical.com
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Email: Daniele.Ceccarelli@ericsson.com Email: Daniele.Ceccarelli@ericsson.com
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
EMail: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
Oscar Gonzalez de Dios Oscar Gonzalez de Dios
Telefonica I+D Telefonica I+D
Email: ogondio@tid.es Email: ogondio@tid.es
Don Fedyk Don Fedyk
Hewlett-Packard Hewlett-Packard
Email: don.fedyk@hp.com Email: don.fedyk@hp.com
Clarence Filsfils Clarence Filsfils
 End of changes. 10 change blocks. 
12 lines changed or deleted 12 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/