draft-ietf-teas-rsvp-te-srlg-collect-05.txt   draft-ietf-teas-rsvp-te-srlg-collect-06.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 October 4, 2016 Telefonica Global CTO Expires November 26, 2016 Telefonica Global CTO
M. Hartley M. Hartley
Z. Ali Z. Ali
Cisco Cisco
C. Margaria C. Margaria
April 4, 2016 May 26, 2016
RSVP-TE Extensions for Collecting SRLG Information RSVP-TE Extensions for Collecting SRLG Information
draft-ietf-teas-rsvp-te-srlg-collect-05 draft-ietf-teas-rsvp-te-srlg-collect-06
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 October 4, 2016. This Internet-Draft will expire on November 26, 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 . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . 11 6. Manageability Considerations . . . . . . . . . . . . . . . . . 10
6.1. Policy Configuration . . . . . . . . . . . . . . . . . . 11 6.1. Policy Configuration . . . . . . . . . . . . . . . . . . . 10
6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 11 6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . 12 8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . . . . 12
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
It is important to understand which Traffic Engineering (TE) links in It is important to understand which Traffic Engineering (TE) links in
the network might be at risk from the same failures. In this sense, the network might be at risk from the same failures. In this sense,
a set of links can constitute a 'shared risk link group' (SRLG) if a set of links can constitute a 'shared risk link group' (SRLG) if
they share a resource whose failure can affect all links in the set they share a resource whose failure can affect all links in the set
[RFC4202]. [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
(Hierarchical LSP) or S-LSP (stitched LSP) can be used for carrying (Hierarchical LSP) or S-LSP (stitched LSP) can be used for carrying
one or more other LSPs. Both of the H-LSP and S-LSP can be formed as one or more other LSPs. Both of the H-LSP and S-LSP can be formed as
a TE link. In such cases, it is important to know the SRLG a TE link. In such cases, it is important to know the SRLG
information of the LSPs that will be used to carry further LSPs. information of the LSPs that will be used to carry further LSPs.
This document provides a mechanism to collect the SRLGs used by a This document provides a signaling mechanism to collect the SRLGs
LSP, which can then be advertized as properties of the TE-link formed used by a LSP, which can then be advertized as properties of the TE-
by that LSP. Note that specification of the the use of the collected link formed by that LSP.
SRLGs is outside the scope of this document.
1.1. Applicability Example: Dual Homing 1.1. Applicability Example: Dual Homing
An interesting use case for the SRLG collection procedures defined in An interesting use case for the SRLG collection procedures defined in
this document is achieving LSP diversity in a dual homing scenario. this document is achieving LSP diversity in a dual homing scenario.
The use case is illustrated in Figure 1, when the overlay model is The use case is illustrated in Figure 1, when the overlay model is
applied as defined in RFC 4208 [RFC4208] . In this example, the applied as defined in RFC 4208 [RFC4208] . In this example, the
exchange of routing information over the User-Network Interface (UNI) exchange of routing information over the User-Network Interface (UNI)
is prohibited by operator policy. is prohibited by operator policy.
skipping to change at page 5, line 17 skipping to change at page 5, line 18
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;
o SRLG data is added to the Path and Resv ROUTE_RECORD Objects (RROs) o SRLG data is added to the Path and Resv ROUTE_RECORD Objects
by all nodes during signaling; (RROs) by all nodes during signaling;
o Changes to previously-signaled SRLG data are made by sending o Changes to previously-signaled SRLG data are made by sending
updated Path and Resv messages as required. updated Path and Resv messages as required.
3.1. SRLG Collection Indication 3.1. SRLG Collection Indication
The ingress node of the LSP needs be capable of indicating whether The ingress node of the LSP needs be capable of indicating whether
the SRLG information of the LSP is to be collected during the the SRLG information of the LSP is to be collected during the
signaling procedure of setting up an LSP. There is no need for signaling procedure of setting up an LSP. There is no need for SRLG
SRLG information to be collected without an explicit request for information to be collected without an explicit request for it being
it being made by the ingress node. made by the ingress node.
It may be preferable for the SRLG collection request to be It may be preferable for the SRLG collection request to be understood
understood by all nodes along the LSP's path, or it may be more by all nodes along the LSP's path, or it may be more important for
important for the LSP to be established successfully even if it the LSP to be established successfully even if it traverses nodes
traverses nodes that cannot supply SRLG information or have not that cannot supply SRLG information or have not implemented the
implemented the procedures specified in this document. It is procedures specified in this document. It is desirable for the
desirable for the ingress node to make the SRLG collection request ingress node to make the SRLG collection request in a manner that
in a manner that best suits its own policy. best suits its own policy.
3.2. SRLG Collection 3.2. SRLG Collection
If requested, the SRLG information is collected during the setup If requested, the SRLG information is collected during the setup of
of an LSP. SRLG information is for each hop is added to the Path an LSP. SRLG information is added by each hop to the Path RRO during
RRO during Path message processing. The same information is also Path message processing. The same information is also added to the
added to the Resv RRO during Resv processing at each hop. The Resv RRO during Resv processing at each hop.
endpoints of the LSP can make use of the collected SRLG
information, for example, for routing, sharing and TE link
configuration purposes.
3.3. SRLG Update 3.3. SRLG Update
When the SRLG information of an existing LSP for which SRLG
When the SRLG information of an existing LSP for which SRLG information was collected during signaling changes, the relevant
information was collected during signaling changes, the relevant nodes of the LSP need to be capable of updating the SRLG information
nodes of the LSP need to be capable of updating the SRLG of the LSP. This means that the signaling procedure needs to be
information of the LSP. This means that that the signaling capable of updating the new SRLG information.
procedure needs to be capable of updating the new SRLG
information.
3.4. SRLG ID definition 3.4. SRLG ID definition
The identifier of an SRLG (SRLG ID) is defined as a 32-bit The identifier of an SRLG (SRLG ID) is defined as a 32-bit quantity
quantity in [RFC4202]. This definition is used in this document. in [RFC4202]. This definition is used in this document.
4. Encodings 4. Encodings
4.1. SRLG Collection Flag 4.1. SRLG Collection Flag
In order to indicate to nodes that SRLG collection is desired, In order to indicate to nodes that SRLG collection is desired, this
this document defines a new flag in the Attribute Flags TLV (see document defines a new flag in the Attribute Flags TLV (see RFC 5420
RFC 5420 [RFC5420]), which MAY be carried in an [RFC5420]), which MAY be carried in an LSP_REQUIRED_ATTRIBUTES or
LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTES Object: LSP_ATTRIBUTES Object:
o Bit Number (specified in Section 8.1): SRLG Collection flag o Bit Number (specified in Section 8.1): 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 for the processing of the Attribute Flags TLV are not The rules for the processing of the Attribute Flags TLV are not
changed. changed.
skipping to change at page 7, line 8 skipping to change at page 7, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |D| Reserved | | Type | Length |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID 1 (4 octets) | | SRLG ID 1 (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ...... ~ ~ ...... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID n (4 octets) | | SRLG ID n (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type (8 bits)
The type of the sub-object. The value is specified in Section 8.2. The type of the sub-object. The value is specified in Section 8.2.
Length Length (8 bits)
The Length field contains the total length of the sub-object in The Length field contains the total length of the sub-object in
octets, including the Type and Length fields. The Length depends on octets, including the Type and Length fields. The Length depends on
the number of SRLG IDs. the number of SRLG IDs.
Direction bit (D-bit) Direction bit (D-bit) (1 bit)
If not set, the SRLGs contained in this sub-object apply to the If not set, the SRLGs contained in this sub-object apply to the
downstream direction. If set, they apply to the upstream direction. downstream direction. If set, they apply to the upstream direction.
Reserved Reserved (15 bits)
This 15-bit field is reserved. It SHOULD be set to zero on This 15-bit field is reserved. It SHOULD be set to zero on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
SRLG ID SRLG ID (4 octets)
This 4 octet field contains one SRLG ID. There is one SRLG ID field This field contains one SRLG ID. There is one SRLG ID field per SRLG
per SRLG collected. There MAY be multiple SRLG ID fields in an SRLG collected. There MAY be multiple SRLG ID fields in an SRLG sub-
sub-object. object.
A node MUST NOT push a SRLG sub-object in the RECORD_ROUTE without A node MUST NOT push a SRLG sub-object in the RECORD_ROUTE without
also pushing either a IPv4 sub-object, a IPv6 sub-object, a also pushing either a IPv4 sub-object, a IPv6 sub-object, a
Unnumbered Interface ID sub-object or a Path Key sub-object. Unnumbered Interface ID sub-object or a Path Key sub-object.
As described in RFC 3209 [RFC3209], the RECORD_ROUTE object is As described in RFC 3209 [RFC3209], the RECORD_ROUTE object is
managed as a stack. The SRLG sub-object SHOULD be pushed by the node managed as a stack. The SRLG sub-object SHOULD be pushed by the node
before the node IP address or link identifier. The SRLG-sub-object before the node IP address or link identifier. The SRLG-sub-object
SHOULD be pushed after the Attribute sub-object, if present, and SHOULD be pushed after the Attribute sub-object, if present, and
after the LABEL sub-object, if requested. It MUST be pushed within after the LABEL sub-object, if requested. It MUST be pushed within
skipping to change at page 8, line 26 skipping to change at page 8, line 21
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.
A node SHOULD NOT add SRLG information without an explicit request
for it being made by the ingress node in the Path message.
When a node receives a Path message which carries an When a node receives a Path message which carries an
LSP_REQUIRED_ATTRIBUTES Object with the SRLG Collection Flag set, if LSP_REQUIRED_ATTRIBUTES Object with 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:
o Error Code 2 (policy) and o Error Code 2 (policy) and
o Error subcode "SRLG Recording Rejected" (see Section 8.3 for o Error subcode "SRLG Recording Rejected" (see Section 8.3 for
value) value)
to reject the Path message. 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
skipping to change at page 10, line 9 skipping to change at page 10, line 7
sub-object for the downstream link. sub-object for the downstream link.
If SRLG data is added for both the upstream and downstream links, If SRLG data is added for both the upstream and downstream links,
the two sets of SRLG data MUST be added in separate SRLG sub- the two sets of SRLG data MUST be added in separate SRLG sub-
objects. A single SRLG sub-object MUST NOT contain a mixture of objects. A single SRLG sub-object MUST NOT contain a mixture of
upstream and downstream SRLGs. When adding a SRLG sub-object to an upstream and downstream SRLGs. When adding a SRLG sub-object to an
RRO, the D-bit MUST be set appropriately to indicate the direction RRO, the D-bit MUST be set appropriately to indicate the direction
of the SRLGs. If an SRLG ID applies in both directions, it SHOULD of the SRLGs. If an SRLG ID applies in both directions, it SHOULD
be added to both the upstream and downstream SRLG sub-objects. be added to both the upstream and downstream SRLG sub-objects.
A node SHOULD NOT add SRLG information without an explicit request
for it being made by the ingress node in the Path message.
Based on the above procedure, the endpoints can get the SRLG Based on the above procedure, the endpoints can get the SRLG
information automatically. Then the endpoints can for instance information automatically. Then the endpoints can for instance
advertise it as a TE link to the routing instance based on the advertise it as a TE link to the routing instance based on the
procedure described in [RFC6107] and configure the SRLG information procedure described in [RFC6107] and configure the SRLG information
of the Forwarding Adjacency (FA) automatically. of the Forwarding Adjacency (FA) automatically.
5.2. SRLG Update 5.2. SRLG Update
When the SRLG information of a link is changed, the endpoints of LSPs When the SRLG information of a link is changed, the endpoints of LSPs
using that link need to be made aware of the changes. When a change using that link need to be made aware of the changes. When a change
skipping to change at page 11, line 4 skipping to change at page 10, line 47
[RFC5420]. It is expected to pass the TLV on unaltered if it appears [RFC5420]. It is expected to pass the TLV on unaltered if it appears
in a LSP_ATTRIBUTES object, or reject the Path message with the in a LSP_ATTRIBUTES object, or reject the Path message with the
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 MUST be capable of being configured: following SRLG processing policy MUST be capable of being configured:
o Whether the node is allowed to participate in SRLG collection. o o Whether the node is allowed to participate in SRLG collection.
Whether the node should notify changes to collected SRLG
information to endpoint nodes as described in section 5.2. o o Whether the node should notify changes to collected SRLG
Whether the SRLG IDs of the domain or specific layer network can information to endpoint nodes as described in section 5.2.
o 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.
A node using RFC 5553 [RFC5553] and PKS MAY apply the same policy. A node using RFC 5553 [RFC5553] and PKS MAY apply the same policy.
6.2. Coherent SRLG IDs 6.2. Coherent SRLG IDs
In a multi-layer multi-domain scenario, SRLG IDs can be configured by In a multi-layer multi-domain scenario, SRLG IDs can be configured by
skipping to change at page 12, line 25 skipping to change at page 12, line 22
-------------- ---------- ---------- ----------- --- --------- -------------- ---------- ---------- ----------- --- ---------
TBD; suggested SRLG Yes No Yes This I-D TBD; suggested SRLG Yes No Yes This I-D
value: 12 Flag value: 12 Flag
8.2. ROUTE_RECORD Object 8.2. ROUTE_RECORD Object
IANA manages the "RSVP PARAMETERS" registry located at IANA manages the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters. This document http://www.iana.org/assignments/rsvp-parameters. This document
introduces a new RRO sub-object: introduces a new RRO sub-object:
Value Description Reference Value Description Reference
--------------------- ------------------- --------- --------------------- ------------------- ---------
TBD; suggested SRLG sub-object This I-D TBD; suggested SRLG sub-object This I-D
value: 34 value: 34
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. located at http://www.iana.org/assignments/rsvp-parameters.
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
--------------------- ----------------------- --------- --------------------- ----------------------- ---------
TBD; suggested SRLG Recording Rejected This I-D TBD; suggested SRLG Recording Rejected This I-D
value: 21 value: 21
9. Contributors 9. Contributors
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 Dieter Beller, Vishnu Pavan Beeram,
The authors would like to thank Dieter Beller, Lou Berger, Igor Lou Berger, Deborah Brungard, Igor Bryskin, Ramon Casellas, Niclas
Bryskin, Ramon Casellas, Niclas Comstedt, Alan Davey, Elwyn Davies Comstedt, Alan Davey, Elwyn Davies, Dhruv Dhody, Himanshu Shah and
and Dhruv Dhody for their useful comments and improvements to this Xian Zhang for their useful comments and improvements to this
document. 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.,
 End of changes. 28 change blocks. 
101 lines changed or deleted 98 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/