draft-ietf-teas-lsp-diversity-06.txt   draft-ietf-teas-lsp-diversity-07.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
Updates RFC4874 F. Zhang, Ed. Updates RFC4874 F. Zhang, Ed.
Expires: April 21, 2017 Huawei Expires: September 28, 2017 Huawei
D. Beller, Ed. D. Beller, Ed.
Nokia Nokia
October 18, 2016 March 27, 2017
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-06.txt draft-ietf-teas-lsp-diversity-07.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 April 21, 2017. This Internet-Draft will expire on September 28, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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 8, line 4 skipping to change at page 8, line 4
the entity that originated the Path-Key, for example the LSR that the entity that originated the Path-Key, for example the LSR that
inserted the Path-Key in the RRO or a management system. inserted the Path-Key in the RRO or a management system.
1.3. Network-Assigned Identifier 1.3. Network-Assigned Identifier
There are scenarios in which the network provides diversity- There are scenarios in which the network provides diversity-
related information for a service that allows the client device related information for a service that allows the client device
to include this information in the signaling message. If the to include this information in the signaling message. If the
Shared Resource Link Group (SRLG) identifier information is both Shared Resource Link Group (SRLG) identifier information is both
available and shareable (by policy) with the ENs, the procedure available and shareable (by policy) with the ENs, the procedure
defined in [DRAFT-SRLG-RECORDING] can be used to collect SRLG defined in [RFC8001] can be used to collect SRLG identifiers
identifiers associated with an LSP (LSP1). When a second LSP associated with an LSP (LSP1). When a second LSP (LSP2) needs to
(LSP2) needs to be diverse with respect to LSP1, the EN be diverse with respect to LSP1, the EN constructing the RSVP
constructing the RSVP signaling message for setting up LSP2 can signaling message for setting up LSP2 can insert the SRLG
insert the SRLG identifiers associated with LSP1 as diversity identifiers associated with LSP1 as diversity constraints into
constraints into the XRO using the procedure described in the XRO using the procedure described in [RFC4874]. However, if
[RFC4874]. However, if the core network SRLG identifiers are the core network SRLG identifiers are either not available or not
either not available or not shareable with the ENs based on shareable with the ENs based on policies enforced by core
policies enforced by core network, existing mechanisms cannot be network, existing mechanisms cannot be used.
used.
In this draft, a signaling mechanism is defined where information In this draft, a signaling mechanism is defined where information
signaled to the CN via the UNI does not require shared knowledge signaled to the CN via the UNI does not require shared knowledge
of core network SRLG information. For this purpose, the concept of core network SRLG information. For this purpose, the concept
of a Path Affinity Set (PAS) is defined for abstracting SRLG of a Path Affinity Set (PAS) is defined for abstracting SRLG
information. The motive behind the introduction of the PAS is to information. The motive behind the introduction of the PAS is to
minimize the exchange of diversity information between the core minimize the exchange of diversity information between the core
network (CNs) and the client devices (ENs). The PAS contains an network (CNs) and the client devices (ENs). The PAS contains an
abstract SRLG identifier associated with a given path rather than abstract SRLG identifier associated with a given path rather than
a detailed SRLG list. The PAS is a single identifier that can be a detailed SRLG list. The PAS is a single identifier that can be
skipping to change at page 12, line 21 skipping to change at page 12, line 21
matching the rest of the diversity identifier. matching the rest of the diversity identifier.
Exclusion Flags (E-Flags): Exclusion Flags (E-Flags):
The Exclusion-Flags are used to communicate the desired The Exclusion-Flags are used to communicate the desired
type(s) of exclusion requested in the IPv4/ IPv6 diversity type(s) of exclusion requested in the IPv4/ IPv6 diversity
subobjects. The following flags are defined. Any subobjects. The following flags are defined. Any
combination of these flags is permitted. Please note that combination of these flags is permitted. Please note that
the exclusion specified by these flags may be modified by the exclusion specified by these flags may be modified by
the value of the Attribute-flags. For example, node the value of the Attribute-flags. For example, node
exclusion flag is ignored for the "Penultimate node" if the exclusion flag is ignored for the "Penultimate node" if
"Penultimate node exception" flag of the Attribute-flags is the "Penultimate node exception" flag of the Attribute-
set. flags is set.
0x01 = SRLG exclusion 0x01 = SRLG exclusion
Indicates that the path of the LSP being signaled is Indicates that the path of the LSP being signaled is
requested to be SRLG-diverse from the excluded path requested to be SRLG-diverse from the excluded path
specified by the IPv4/ IPv6 Diversity XRO subobject. specified by the IPv4/ IPv6 Diversity XRO subobject.
0x02 = Node exclusion 0x02 = Node exclusion
Indicates that the path of the LSP being signaled is Indicates that the path of the LSP being signaled is
skipping to change at page 13, line 17 skipping to change at page 13, line 20
IPv4 / IPv6 Diversity Identifier source address: IPv4 / IPv6 Diversity Identifier source address:
This field MUST be set to the IPv4/ IPv6 address of the This field MUST be set to the IPv4/ IPv6 address of the
node that assigns the diversity identifier. Depending on node that assigns the diversity identifier. Depending on
the diversity identifier type, the diversity identifier the diversity identifier type, the diversity identifier
source may be a client node, PCE entity or network node. source may be a client node, PCE entity or network node.
Specifically: Specifically:
o When the diversity identifier type is set to "IPv4/ IPv6 o When the diversity identifier type is set to "IPv4/ IPv6
Client Initiated Identifier", the value is set to IPv4/ Client Initiated Identifier", the value MUST be set to
IPv6 tunnel sender address of the reference LSP against IPv4/ IPv6 tunnel sender address of the reference LSP
which diversity is desired. IPv4/ IPv6 tunnel sender against which diversity is desired. IPv4/ IPv6 tunnel
address is as defined in [RFC3209]. sender address is as defined in [RFC3209].
o When the diversity identifier type is set to "IPv4/ IPv6 o When the diversity identifier type is set to "IPv4/ IPv6
PCE Allocated Identifier", the value indicates the IPv4/ PCE Allocated Identifier", the value MUST be set to the
IPv6 address of the node that assigned the Path Key IPv4/ IPv6 address of the node that assigned the Path Key
identifier and that can return an expansion of the Path identifier and that can return an expansion of the Path
Key or use the Path Key as exclusion in a path Key or use the Path Key as exclusion in a path
computation. The Path Key is defined in [RFC5553]. The computation. The Path Key is defined in [RFC5553]. The
PCE-ID is carried in the Identifier Source Address field PCE-ID is carried in the Identifier Source Address field
of the subobject. of the subobject.
o When the diversity identifier type is set to "IPv4/ IPv6 o When the diversity identifier type is set to "IPv4/ IPv6
Network Assigned Identifier", the value indicates the Network Assigned Identifier", the value MUST be set to the
IPv4/ IPv6 address of the node publishing the Path IPv4/ IPv6 address of the node publishing the Path
Affinity Set (PAS). Affinity Set (PAS).
Diversity Identifier Value: Diversity Identifier Value:
Encoding for this field depends on the diversity identifier Encoding for this field depends on the diversity identifier
type, as defined in the following. type, as defined in the following.
When the diversity identifier type is set to "Client When the diversity identifier type is set to "Client
Initiated Identifier" in IPv4 Diversity XRO subobject, the Initiated Identifier" in IPv4 Diversity XRO subobject, the
skipping to change at page 17, line 17 skipping to change at page 17, line 17
o When the "processing node exception" flag is set, the o When the "processing node exception" flag is set, the
exclusion MUST be ignored for the node processing the XRO exclusion MUST be ignored for the node processing the XRO
or EXRS subobject. or EXRS subobject.
o When the "destination node exception" flag is set, the o When the "destination node exception" flag is set, the
exclusion MUST be ignored for the destination node in exclusion MUST be ignored for the destination node in
processing the XRO subobject. The destination node processing the XRO subobject. The destination node
exception for the EXRS subobject applies to the explicit exception for the EXRS subobject applies to the explicit
node identified by the ERO subobject that identifies the node identified by the ERO subobject that identifies the
next abstract node. This flag is only processed if the L next abstract node. When the "destination node exception"
bit is set in the ERO subobject that identifies the next flag is set in the EXRS subobject, exclusion MUST be
abstract node. ignored for the said node (i.e., the next abstract node).
o When the "penultimate node exception" flag is set in the o When the "penultimate node exception" flag is set in the
XRO subobject, the exclusion MUST be ignored for the XRO subobject, the exclusion MUST be ignored for the
penultimate node on the path of the LSP being established. penultimate node on the path of the LSP being established.
The penultimate node exception for the EXRS subobject The penultimate node exception for the EXRS subobject
applies to the node before the explicit node identified by applies to the node before the explicit node identified by
the ERO subobject that identifies the next abstract node. the ERO subobject that identifies the next abstract node.
This flag is only processed if the L bit is set in the ERO When the "penultimate node exception" flag is set in the
subobject that identifies the next abstract node. EXRS subobject, the exclusion MUST be ignored for the said
node (i.e., the node before the next abstract node).
If the L-flag of the diversity XRO subobject or diversity EXRS If the L-flag of the diversity XRO subobject or diversity EXRS
subobject is not set, the processing node proceeds as follows. subobject is not set, the processing node proceeds as follows.
- If the Diversity Identifier Type is set to "IPv4/IPv6 Client - If the Diversity Identifier Type is set to "IPv4/IPv6 Client
Initiated Identifiers", the processing node MUST ensure that Initiated Identifiers", the processing node MUST ensure that
the path calculated/ expended for the signaled LSP is diverse the path calculated/ expended for the signaled LSP is diverse
from the route taken by the LSP identified in the Diversity from the route taken by the LSP identified in the Diversity
Identifier Value field. Identifier Value field.
skipping to change at page 22, line 41 skipping to change at page 22, line 41
[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
Engineering (RSVP-TE) Extensions", RFC 3473, January Engineering (RSVP-TE) Extensions", RFC 3473, January
2003. 2003.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude
Routes - Extension to Resource ReserVation Protocol- Routes - Extension to Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE)", RFC 4874, April 2007. Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, [RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur,
"Resource Reservation Protocol (RSVP) Extensions for Path Key "Resource Reservation Protocol (RSVP) Extensions for
Support", RFC 5553, May 2009. Path Key Support", RFC 5553, May 2009.
6.2. Informative References 6.2. Informative References
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) "Generalized Multiprotocol Label Switching (GMPLS)
User-Network Interface (UNI): Resource ReserVation User-Network Interface (UNI): Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Support for the Protocol-Traffic Engineering (RSVP-TE) Support for the
Overlay Model", RFC 4208, October 2005. Overlay Model", RFC 4208, October 2005.
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, [RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita,
N., and G. Ash, "Crankback Signaling Extensions for N., and G. Ash, "Crankback Signaling Extensions for
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. [RFC8001] F. Zhang, D. Li, O. Gonzalez de Dios, C. Margaria,
Margaria, "RSVP-TE Extensions for Collecting SRLG "RSVP-TE Extensions for Collecting SRLG Information",
Information", draft-ietf-teas-rsvp-te-srlg-collect-08, RFC 8001, January 2017.
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.
[RFC5251] Fedyk, D. (Ed.), Rekhter, Y. (Ed.), Papadimitriou, D., [RFC5251] Fedyk, D. (Ed.), Rekhter, Y. (Ed.), Papadimitriou, D.,
Rabbat, R., and Berger, L., "Layer 1 VPN Basic Mode", Rabbat, R., and Berger, L., "Layer 1 VPN Basic Mode",
RFC 5251, July 2008. RFC 5251, July 2008.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
 End of changes. 14 change blocks. 
37 lines changed or deleted 36 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/