draft-ietf-ccamp-te-metric-recording-03.txt   draft-ietf-ccamp-te-metric-recording-04.txt 
CCAMP Working Group Zafar Ali CCAMP Working Group Zafar Ali
Internet Draft George Swallow Internet Draft George Swallow
Intended status: Standard Track Clarence Filsfils Intended status: Standard Track Clarence Filsfils
Expires: August 13, 2014 Matt Hartley Expires: February 20, 2015 Matt Hartley
Cisco Systems Cisco Systems
Kenji Kumaki Kenji Kumaki
KDDI Corporation KDDI Corporation
Ruediger Kunze Ruediger Kunze
Deutsche Telekom AG Deutsche Telekom AG
February 14, 2014 August 20, 2014
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
extension for recording TE Metric of a Label Switched Path extension for recording TE Metric of a Label Switched Path
draft-ietf-ccamp-te-metric-recording-03.txt draft-ietf-ccamp-te-metric-recording-04.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 months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
This Internet-Draft will expire on August 13, 2014. This Internet-Draft will expire on February 20, 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 2, line 5 skipping to change at page 2, line 5
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative be modified outside the IETF Standards Process, and derivative
works of it may not be created outside the IETF Standards Process, works of it may not be created outside the IETF Standards Process,
except to format it for publication as an RFC or to translate it except to format it for publication as an RFC or to translate it
into languages other than English. into languages other than English.
Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt
Abstract Abstract
There are many scenarios in which Traffic Engineering (TE) metrics There are many scenarios in which Traffic Engineering (TE) metrics
such as cost, latency and latency variation associated with a such as cost, latency and latency variation associated with a
Forwarding Adjacency (FA) or Routing Adjacency (RA) Label Switched Forwarding Adjacency (FA) or Routing Adjacency (RA) Label Switched
Path (LSP) are not available to the ingress and egress nodes. This Path (LSP) are not available to the ingress and egress nodes. This
draft provides extensions for the Resource ReserVation Protocol- draft provides extensions for the Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) for the support of the discovery of Traffic Engineering (RSVP-TE) for the support of the discovery of
cost, latency and latency variation of an LSP. cost, latency and latency variation of an LSP.
skipping to change at page 3, line 4 skipping to change at page 3, line 4
2.3. Cost, Latency and Latency Variation Update................4 2.3. Cost, Latency and Latency Variation Update................4
3. RSVP-TE signaling extensions................................5 3. RSVP-TE signaling extensions................................5
3.1. Cost, Latency, and Latency Variation Collection Flags.....5 3.1. Cost, Latency, and Latency Variation Collection Flags.....5
3.4. Cost subobject............................................5 3.4. Cost subobject............................................5
3.5. Latency subobject.........................................6 3.5. Latency subobject.........................................6
3.6. Latency Variation subobject...............................7 3.6. Latency Variation subobject...............................7
3.7. Signaling Procedures......................................8 3.7. Signaling Procedures......................................8
4. Security Considerations....................................12 4. Security Considerations....................................12
5. IANA Considerations........................................12 5. IANA Considerations........................................12
5.1. RSVP Attribute Bit Flags.................................12 5.1. RSVP Attribute Bit Flags.................................12
Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt
5.2. New RSVP error sub-code..................................13 5.2. New RSVP error sub-code..................................13
6. Acknowledgments............................................14 6. Acknowledgments............................................14
7. References.................................................14 7. References.................................................14
7.1. Normative References.....................................14 7.1. Normative References.....................................14
7.2. Informative References...................................14 7.2. Informative References...................................14
1. Introduction 1. Introduction
In certain networks, such as financial information networks, In certain networks, such as financial information networks,
skipping to change at page 4, line 5 skipping to change at page 4, line 5
1.1.1. GMPLS 1.1.1. GMPLS
In Generalized Multi-Protocol Label Switching (GMPLS) networks In Generalized Multi-Protocol Label Switching (GMPLS) networks
signaling bidirectional LSPs, the egress node cannot determine signaling bidirectional LSPs, the egress node cannot determine
the cost, latency and latency variation properties of the LSP the cost, latency and latency variation properties of the LSP
path. A multi-domain or multi-layer network is an example of path. A multi-domain or multi-layer network is an example of
such networks. A GMPLS User-Network Interface (UNI) [RFC4208] is such networks. A GMPLS User-Network Interface (UNI) [RFC4208] is
also an example of such networks. also an example of such networks.
Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt
1.1.2. Inter-area tunnels with loose-hops 1.1.2. Inter-area tunnels with loose-hops
When a LSP is established over multiple IGP-areas using loose When a LSP is established over multiple IGP-areas using loose
hops in the ERO, the ingress node only has knowledge of the hops in the ERO, the ingress node only has knowledge of the
first IGP-area traversed by the LSP. In this case, it cannot first IGP-area traversed by the LSP. In this case, it cannot
determine the cost, latency and latency variation properties of determine the cost, latency and latency variation properties of
the LSP path. the LSP path.
2. RSVP-TE Requirements 2. RSVP-TE Requirements
skipping to change at page 5, line 4 skipping to change at page 5, line 4
rerouted, the endpoints of the re-routed segment need to be rerouted, the endpoints of the re-routed segment need to be
capable of updating the cost, latency and latency variation capable of updating the cost, latency and latency variation
information of the path. Any node which adds cost, latency or information of the path. Any node which adds cost, latency or
latency variation information to an LSP during initial setup, latency variation information to an LSP during initial setup,
needs to signal changes to these values to both endpoints. needs to signal changes to these values to both endpoints.
2.4. Cost Definition 2.4. Cost Definition
Although the terms latency and latency variation are well Although the terms latency and latency variation are well
understood, "cost" may be ambiguous; in particular, in the understood, "cost" may be ambiguous; in particular, in the
Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt
context of a LSP that traverses nodes and links operated by context of a LSP that traverses nodes and links operated by
different entities, there may be no common definition of cost. different entities, there may be no common definition of cost.
However, there are situations in which the entire LSP may be However, there are situations in which the entire LSP may be
within a single AS (e.g. inter-area LSPs) in which cost within a single AS (e.g. inter-area LSPs) in which cost
discovery is useful. discovery is useful.
The precise meaning and interpretation of numerical costs is a The precise meaning and interpretation of numerical costs is a
matter for the network operator. For the purposes of this matter for the network operator. For the purposes of this
document, two constraints are assumed: document, two constraints are assumed:
skipping to change at page 6, line 5 skipping to change at page 6, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved (must be zero) | | Type | Length | Reserved (must be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Cost | | Downstream Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Cost | | Upstream Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBA1 - Cost subobject (to be assigned by IANA). Type: TBA1 - Cost subobject (to be assigned by IANA).
Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt
Length: The Length value is set to 8 or 12 depending on the Length: The Length value is set to 8 or 12 depending on the
presence of Upstream Cost information. It MUST NOT be set to presence of Upstream Cost information. It MUST NOT be set to
any other value. any other value.
Reserved: This field is reserved for future use. It MUST be Reserved: This field is reserved for future use. It MUST be
set to 0 on transmission and MUST be ignored when received. set to 0 on transmission and MUST be ignored when received.
Downstream Cost: Cost of the local link along the route of Downstream Cost: Cost of the local link along the route of
the LSP in the direction of the tail-end node, encoded as a the LSP in the direction of the tail-end node, encoded as a
skipping to change at page 7, line 4 skipping to change at page 7, line 4
A-bit: These fields represent the Anomalous (A) bit A-bit: These fields represent the Anomalous (A) bit
associated with the Downstream and Upstream Delay associated with the Downstream and Upstream Delay
respectively, as defined in [DRAFT-OSPF-TE-METRIC]. respectively, as defined in [DRAFT-OSPF-TE-METRIC].
Reserved: These fields are reserved for future use. They MUST Reserved: These fields are reserved for future use. They MUST
be set to 0 when sent and MUST be ignored when received. be set to 0 when sent and MUST be ignored when received.
Downstream Delay: Delay of the local link along the route of Downstream Delay: Delay of the local link along the route of
the LSP in the direction of the tail-end node, encoded as 24- the LSP in the direction of the tail-end node, encoded as 24-
bit integer, as defined in [DRAFT-OSPF-TE-METRIC]. When set bit integer, as defined in [DRAFT-OSPF-TE-METRIC]. When set
Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt
to the maximum value 16,777,215 (16.777215 sec), the delay is to the maximum value 16,777,215 (16.777215 sec), the delay is
at least that value and may be larger. at least that value and may be larger.
Upstream Delay: Delay of the local link along the route of Upstream Delay: Delay of the local link along the route of
the LSP in the direction of the head-end node, encoded as 24- the LSP in the direction of the head-end node, encoded as 24-
bit integer, as defined in [DRAFT-OSPF-TE-METRIC]. When set bit integer, as defined in [DRAFT-OSPF-TE-METRIC]. When set
to the maximum value 16,777,215 (16.777215 sec), the delay is to the maximum value 16,777,215 (16.777215 sec), the delay is
at least that value and may be larger. at least that value and may be larger.
skipping to change at page 8, line 4 skipping to change at page 8, line 4
along the route of the LSP in the direction of the tail-end along the route of the LSP in the direction of the tail-end
node, encoded as 24-bit integer, as defined in [DRAFT-OSPF- node, encoded as 24-bit integer, as defined in [DRAFT-OSPF-
TE-METRIC]. When set to the maximum value 16,777,215 TE-METRIC]. When set to the maximum value 16,777,215
(16.777215 sec), the delay is at least that value and may be (16.777215 sec), the delay is at least that value and may be
larger. larger.
Upstream Delay Variation: Delay Variation of the local link Upstream Delay Variation: Delay Variation of the local link
along the route of the LSP in the direction of the head-end along the route of the LSP in the direction of the head-end
node, encoded as 24-bit integer. When set to 0, it has not node, encoded as 24-bit integer. When set to 0, it has not
been measured. When set to the maximum value 16,777,215 been measured. When set to the maximum value 16,777,215
Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt
(16.777215 sec), the delay is at least that value and may be (16.777215 sec), the delay is at least that value and may be
larger. larger.
4. Signaling Procedures 4. Signaling Procedures
The rules for processing the LSP_ATTRIBUTES and The rules for processing the LSP_ATTRIBUTES and
LSP_REQUIRED_ATTRIBUTES Objects and RRO defined in [RFC5420] are LSP_REQUIRED_ATTRIBUTES Objects and RRO defined in [RFC5420] are
not changed. not changed.
skipping to change at page 9, line 4 skipping to change at page 9, line 4
. If local policy disallows providing the requested . If local policy disallows providing the requested
information to the endpoints, the node MUST return a Path information to the endpoints, the node MUST return a Path
Error message with error code "Policy Control Failure" (2) Error message with error code "Policy Control Failure" (2)
and subcode "Cost Recording Rejected" (value to be assigned and subcode "Cost Recording Rejected" (value to be assigned
by IANA, suggested value 105). by IANA, suggested value 105).
. It SHOULD add a Cost subobject to the Path and Resv RROs . It SHOULD add a Cost subobject to the Path and Resv RROs
for the LSP. It SHOULD supply only downstream information for the LSP. It SHOULD supply only downstream information
for a unidirectional LSP, and SHOULD provide both upstream for a unidirectional LSP, and SHOULD provide both upstream
Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt
and downstream information if a bidirectional LSP is being and downstream information if a bidirectional LSP is being
signaled. signaled.
. If Cost information is not known, a Cost subobject SHOULD . If Cost information is not known, a Cost subobject SHOULD
NOT be added to either the Path or Resv RRO. NOT be added to either the Path or Resv RRO.
If a node receives a Path message containing a LSP_ATTRIBUTES If a node receives a Path message containing a LSP_ATTRIBUTES
Object with the Cost Collection Flag set in the Attribute Flags Object with the Cost Collection Flag set in the Attribute Flags
TLV: TLV:
skipping to change at page 10, line 4 skipping to change at page 10, line 4
set in the Attribute Flags TLV: set in the Attribute Flags TLV:
. If local policy disallows providing the requested . If local policy disallows providing the requested
information to the endpoints, the node MUST return a Path information to the endpoints, the node MUST return a Path
Error message with error code "Policy Control Failure" (2) Error message with error code "Policy Control Failure" (2)
and subcode "Latency Recording Rejected" (value to be and subcode "Latency Recording Rejected" (value to be
assigned by IANA, suggested value 106). assigned by IANA, suggested value 106).
. It SHOULD add a Latency subobject to the Path and Resv . It SHOULD add a Latency subobject to the Path and Resv
RROs for the LSP. It SHOULD supply only downstream RROs for the LSP. It SHOULD supply only downstream
Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt
information for a unidirectional LSP, and SHOULD provide information for a unidirectional LSP, and SHOULD provide
both upstream and downstream information if a bidirectional both upstream and downstream information if a bidirectional
LSP is being signaled. LSP is being signaled.
. If Latency information is not known, a Latency subobject . If Latency information is not known, a Latency subobject
SHOULD NOT be added to either the Path or Resv RRO. SHOULD NOT be added to either the Path or Resv RRO.
If a node receives a Path message containing a LSP_ATTRIBUTES If a node receives a Path message containing a LSP_ATTRIBUTES
Object with the Latency Collection Flag set in the Attribute Object with the Latency Collection Flag set in the Attribute
skipping to change at page 11, line 4 skipping to change at page 11, line 4
Collection Flag set in the Attribute Flags TLV: Collection Flag set in the Attribute Flags TLV:
. If local policy disallows providing the requested . If local policy disallows providing the requested
information to the endpoints, the node MUST return a Path information to the endpoints, the node MUST return a Path
Error message with error code "Policy Control Failure" (2) Error message with error code "Policy Control Failure" (2)
and subcode "Latency Variation Recording Rejected" (value and subcode "Latency Variation Recording Rejected" (value
to be assigned by IANA, suggested value 107). to be assigned by IANA, suggested value 107).
. It SHOULD add a Latency Variation subobject to the Path . It SHOULD add a Latency Variation subobject to the Path
and Resv RROs for the LSP. It SHOULD supply only downstream and Resv RROs for the LSP. It SHOULD supply only downstream
Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt
information for a unidirectional LSP, and SHOULD provide information for a unidirectional LSP, and SHOULD provide
both upstream and downstream information if a bidirectional both upstream and downstream information if a bidirectional
LSP is being signaled. LSP is being signaled.
. If Latency Variation information is not known, a Latency . If Latency Variation information is not known, a Latency
subobject SHOULD NOT be added to either the Path or Resv subobject SHOULD NOT be added to either the Path or Resv
RRO. RRO.
If a node receives a Path message containing a LSP_ATTRIBUTES If a node receives a Path message containing a LSP_ATTRIBUTES
skipping to change at page 12, line 5 skipping to change at page 12, line 5
When the cost, latency and/or latency variation information of a When the cost, latency and/or latency variation information of a
link is changed, the corresponding metric values for the LSPs link is changed, the corresponding metric values for the LSPs
using that link should also be updated. If node has added Cost, using that link should also be updated. If node has added Cost,
Latency and/or Latency Variation subobjects to the Path or Resv Latency and/or Latency Variation subobjects to the Path or Resv
RRO, the procedures defined in Section 4.4.3 of RFC 3209 RRO, the procedures defined in Section 4.4.3 of RFC 3209
[RFC3209] MUST be used to communicate any changes to relevant [RFC3209] MUST be used to communicate any changes to relevant
information to the other nodes on the LSP's path. The node need information to the other nodes on the LSP's path. The node need
not send an update for changes to information which has not been not send an update for changes to information which has not been
added to the RRO. added to the RRO.
Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt
5. Endpoint processing 5. Endpoint processing
The ingress and egress nodes of a LSP may calculate the end-to- The ingress and egress nodes of a LSP may calculate the end-to-
end cost, latency and/or latency variation properties of the LSP end cost, latency and/or latency variation properties of the LSP
from the supplied values in the Resv or Path RRO respectively. from the supplied values in the Resv or Path RRO respectively.
Typically, cost and latency are additive metrics, but latency Typically, cost and latency are additive metrics, but latency
variation is not an additive metric. The means by which the variation is not an additive metric. The means by which the
ingress and egress nodes compute the end-to-end cost, latency ingress and egress nodes compute the end-to-end cost, latency
skipping to change at page 13, line 4 skipping to change at page 13, line 4
document. document.
This document introduces the following three new Attribute This document introduces the following three new Attribute
Bit Flag: Bit Flag:
- Bit number: TBD (recommended bit position 11) - Bit number: TBD (recommended bit position 11)
- Defining RFC: this I-D - Defining RFC: this I-D
- Name of bit: Cost Collection Flag - Name of bit: Cost Collection Flag
Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt
- Bit number: TBD (recommended bit position 12) - Bit number: TBD (recommended bit position 12)
- Defining RFC: this I-D - Defining RFC: this I-D
- Name of bit: Latency Collection Flag - Name of bit: Latency Collection Flag
- Bit number: TBD (recommended bit position 13) - Bit number: TBD (recommended bit position 13)
- Defining RFC: this I-D - Defining RFC: this I-D
skipping to change at page 14, line 5 skipping to change at page 14, line 5
Cost Recoding Rejected To be assigned by IANA. Cost Recoding Rejected To be assigned by IANA.
Suggested Value: 105. Suggested Value: 105.
Latency Recoding Rejected To be assigned by IANA. Latency Recoding Rejected To be assigned by IANA.
Suggested Value: 106. Suggested Value: 106.
Latency Variation Recoding Rejected To be assigned by IANA. Latency Variation Recoding Rejected To be assigned by IANA.
Suggested Value: 107. Suggested Value: 107.
Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt
8. Acknowledgments 8. Acknowledgments
Authors would like to thank Ori Gerstel, Gabriele Maria Authors would like to thank Ori Gerstel, Gabriele Maria
Galimberti, Luyuan Fang and Walid Wakim for their review Galimberti, Luyuan Fang and Walid Wakim for their review
comments. comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
skipping to change at page 15, line 5 skipping to change at page 15, line 5
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.
[RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation
Protocol (RSVP) -- Version 1 Message Processing Protocol (RSVP) -- Version 1 Message Processing
Rules", RFC 2209, September 1997. Rules", RFC 2209, September 1997.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt
[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-ccamp-rsvp-te-srlg- Information", draft-ietf-ccamp-rsvp-te-srlg-
collect.txt, work in progress. collect.txt, work in progress.
Authors' Addresses Authors' Addresses
Zafar Ali Zafar Ali
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 18 change blocks. 
18 lines changed or deleted 18 lines changed or added

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