draft-ietf-ccamp-rsvp-te-srlg-collect-03.txt   draft-ietf-ccamp-rsvp-te-srlg-collect-04.txt 
Network Working Group F. Zhang, Ed. Network Working Group F. Zhang, Ed.
Internet-Draft D. Li Internet-Draft Huawei
Intended status: Standards Track Huawei Intended status: Standards Track O. Gonzalez de Dios, Ed.
Expires: April 04, 2014 O. Gonzalez de Dios, Ed. Expires: August 18, 2014 Telefonica Global CTO
Telefonica I+D D. Li
Huawei
C. Margaria C. Margaria
Nokia Siemens Networks
M. Hartley M. Hartley
Z. Ali
Cisco Cisco
October 01, 2013 February 14, 2014
RSVP-TE Extensions for Collecting SRLG Information RSVP-TE Extensions for Collecting SRLG Information
draft-ietf-ccamp-rsvp-te-srlg-collect-03 draft-ietf-ccamp-rsvp-te-srlg-collect-04
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 LSP. link formed by a LSP.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 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 April 04, 2014. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
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
skipping to change at page 2, line 20 skipping to change at page 2, line 22
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. RSVP-TE Requirements . . . . . . . . . . . . . . . . . . . . 3 2. RSVP-TE Requirements . . . . . . . . . . . . . . . . . . . . 3
2.1. SRLG Collection Indication . . . . . . . . . . . . . . . 3 2.1. SRLG Collection Indication . . . . . . . . . . . . . . . 3
2.2. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 3 2.2. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 3
2.3. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 3 2.3. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 3
3. RSVP-TE Extensions (Encoding) . . . . . . . . . . . . . . . . 3 3. RSVP-TE Extensions (Encoding) . . . . . . . . . . . . . . . . 3
3.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . 3 3.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . 3
3.2. SRLG sub-object . . . . . . . . . . . . . . . . . . . . . 4 3.2. SRLG sub-object . . . . . . . . . . . . . . . . . . . . . 4
4. Signaling Procedures . . . . . . . . . . . . . . . . . . . . 5 4. Signaling Procedures . . . . . . . . . . . . . . . . . . . . 4
4.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 5 4.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 4
4.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 6
5. Manageability Considerations . . . . . . . . . . . . . . . . 7 5. Manageability Considerations . . . . . . . . . . . . . . . . 6
5.1. Policy Configuration . . . . . . . . . . . . . . . . . . 7 5.1. Policy Configuration . . . . . . . . . . . . . . . . . . 6
5.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 7 5.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . 8 7.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . 7
7.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 8 7.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 7
7.2.1. SRLG sub-object Flags . . . . . . . . . . . . . . . . 9 7.3. Policy Control Failure Error subcodes . . . . . . . . . . 8
7.3. Policy Control Failure Error subcodes . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 9 9. Normative References . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
10. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
It is important to understand which TE links in the network might be It is important to understand which TE links in the network might be
at risk from the same failures. In this sense, a set of links may at risk from the same failures. In this sense, a set of links may
constitute a 'shared risk link group' (SRLG) if they share a resource constitute a 'shared risk link group' (SRLG) if they share a resource
whose failure may affect all links in the set [RFC4202]. whose failure may affect all links in the set [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
skipping to change at page 4, line 11 skipping to change at page 4, line 11
The rules of the processing of the Attribute Flags TLV are not The rules of the processing of the Attribute Flags TLV are not
changed. changed.
3.2. SRLG sub-object 3.2. SRLG sub-object
This document defines a new RRO sub-object (ROUTE_RECORD sub-object) This document defines a new RRO sub-object (ROUTE_RECORD sub-object)
to record the SRLG information of the LSP. Its format is modeled on to record the SRLG information of the LSP. Its format is modeled on
the RRO sub-objects defined in RFC 3209 [RFC3209]. the RRO sub-objects defined in RFC 3209 [RFC3209].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Flags | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID 1 (4 bytes) | | SRLG ID 1 (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ...... ~ ~ ...... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID n (4 bytes) | | SRLG ID n (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
The type of the sub-object, to be assigned by IANA, which is The type of the sub-object, to be assigned by IANA, which is
recommended 34. recommended 34.
Length Length
The Length contains the total length of the sub-object in bytes, The Length contains the total length of the sub-object in bytes,
including the Type and Length fields. The Length depends on the including the Type and Length fields. The Length depends on the
number of SRLG IDs. number of SRLG IDs.
Flags
The Flags are used to indicate properties of the SRLG-list contained
in the sub-object.
0x01 = SRLG-list edited
If set, this flag indicates that the SRLG-list contained in the
RRO sub-object has been edited in some way by a node during
signaling in accordance with that node's policy.
0x02 = Partial SRLG-list
If set, this flag indicates that the SRLG-list contained in this
RRO sub-object is known to be incomplete.
SRLG Id
The 32-bit identifier of the SRLG.
Reserved
This field is reserved. It SHOULD be set to zero on transmission and
MUST be ignored on receipt.
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.
4. Signaling Procedures 4. Signaling Procedures
4.1. SRLG Collection 4.1. SRLG Collection
Typically, the head node gets the route information of an LSP by Typically, the head node gets the route information of an LSP by
adding a RRO which contains the sender's IP addresses in the Path adding a RRO which contains the sender's IP addresses in the Path
message. If a head node also desires SRLG recording, it sets the message. If a head node also desires SRLG recording, it sets the
skipping to change at page 6, line 19 skipping to change at page 5, line 39
When a node receives a Resv message for an LSP for which SRLG When a node receives a Resv message for an LSP for which SRLG
Collection is specified, if local policy determines that the SRLG Collection is specified, if local policy determines that the SRLG
information should not be provided to the endpoints, if the SRLG- information should not be provided to the endpoints, if the SRLG-
recording request was in a LSP_REQUIRED_ATTRIBUTES object, then a recording request was in a LSP_REQUIRED_ATTRIBUTES object, then a
ResvErr with Error code 2 (policy) and Error subcode "SRLG Recording ResvErr with Error code 2 (policy) and Error subcode "SRLG Recording
Rejected" (value to be assigned by IANA, suggest value 108) MUST be Rejected" (value to be assigned by IANA, suggest value 108) MUST be
sent. If the request was in a LSP_ATTRIBUTES object, then a ResvErr sent. If the request was in a LSP_ATTRIBUTES object, then a ResvErr
SHOULD NOT be generated, but SRLG information must not be added in SHOULD NOT be generated, but SRLG information must not be added in
the RRO. Otherwise, if local policy allows to provide the SRLG the RRO. Otherwise, if local policy allows to provide the SRLG
informatin, it MUST add an SRLG sub-object to the RRO to carry the information, it MUST add an SRLG sub-object to the RRO to carry the
SRLG information in the upstream direction. When the Resv message SRLG information in the upstream direction. When the Resv message
arrives at the head node, the head node can get the SRLG information arrives at the head node, the head node can get the SRLG information
from the RRO in the same way as the tail node. from the RRO in the same way as the tail node.
Note that a link's SRLG information for the upstream direction cannot Note that a link's SRLG information for the upstream direction cannot
be assumed to be the same as that in the downstream. be assumed to be the same as that in the downstream.
o For Path and Resv messages for a unidirectional LSP, a node SHOULD o For Path and Resv messages for a unidirectional LSP, a node SHOULD
include SRLG sub-objects in the RRO for the downstream data link include SRLG sub-objects in the RRO for the downstream data link
only. only.
skipping to change at page 7, line 5 skipping to change at page 6, line 19
both Path messages and Resv messages. That is, the SRLG sub- both Path messages and Resv messages. That is, the SRLG sub-
object for the upstream link is added to the RRO before the SRLG object for the upstream link is added to the RRO before the SRLG
sub-object for the downstream link. sub-object for the downstream link.
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 FA automatically. of the FA automatically.
It is noted that a node (e.g. the edge node of a domain) may edit the
RRO to remove the route information (e.g. node, interface identifier
information) before forwarding it due to some reasons
(e.g.confidentiality or reduce the size of RRO). A node MAY edit
SRLG information within the RRO of a Path or Resv message if dictated
by its local policy. If a node makes such an alteration to an
existing RRO object, it SHOULD set the "SRLG-list edited" flag in the
edited RRO sub-object to indicate to other nodes that this has been
done.
4.2. SRLG Update 4.2. SRLG Update
When the SRLG information of a link is changed, the LSPs using that When the SRLG information of a link is changed, the LSPs using that
link should be aware of the changes. The procedures defined in link should be aware of the changes. The procedures defined in
Section 4.4.3 of RFC 3209 [RFC3209] MUST be used to refresh the SRLG Section 4.4.3 of RFC 3209 [RFC3209] MUST be used to refresh the SRLG
information if the SRLG change is to be communicated to other nodes information if the SRLG change is to be communicated to other nodes
according to the local node's policy. If local policy is that the according to the local node's policy. If local policy is that the
SRLG change should be suppressed or would result in no change to the SRLG change should be suppressed or would result in no change to the
previously signaled SRLG-list, the node need not send an update previously signaled SRLG-list, the node need not send an update.
5. Manageability Considerations 5. Manageability Considerations
5.1. Policy Configuration 5.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 should be capable of being following SRLG processing policy should be capable of being
configured: configured:
o Whether the SRLG IDs of the domain or specific layer network can 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 or removed entirely. whether they should be summarized or removed entirely.
o If SRLGs are summarized or removed, whether the "SRLG-list edited"
flag is set in affected SRLG RRO-sub-objects and .
o If SRLGs are summarized or removed, whether the "SRLG-list edited"
and "Partial SRLG-list" flags are set in affected SRLG RRO-sub-
objects.
5.2. Coherent SRLG IDs 5.2. Coherent SRLG IDs
In a multi-layer multi-domain scenario, SRLG ids may be configured by In a multi-layer multi-domain scenario, SRLG ids may be configured by
different management entities in each layer/domain. In such different management entities in each layer/domain. In such
scenarios, maintaining a coherent set of SRLG IDs is a key scenarios, maintaining a coherent set of SRLG IDs is a key
requirement in order to be able to use the SRLG information properly. requirement in order to be able to use the SRLG information properly.
Thus, SRLG IDs must be unique. Note that current procedure is Thus, SRLG IDs must be unique. Note that current procedure is
targeted towards a scenario where the different layers and domains targeted towards a scenario where the different layers and domains
belong to the same operator, or to several coordinated administrative belong to the same operator, or to several coordinated administrative
groups. Ensuring the aforementioned coherence of SRLG IDs is beyond groups. Ensuring the aforementioned coherence of SRLG IDs is beyond
the scope of this documen the scope of this document.
Further scenarios, where coherence in the SRLG IDs cannot be Further scenarios, where coherence in the SRLG IDs cannot be
guaranteed are out of the scope of the present document and are left guaranteed are out of the scope of the present document and are left
for further study. for further study.
6. Security Considerations 6. Security Considerations
This document does not introduce any additional security issues above This document does not introduce any additional security issues above
those identified in [RFC5920][RFC3209][RFC3473] those identified in [RFC5920][RFC3209][RFC3473]
skipping to change at page 8, line 36 skipping to change at page 7, line 34
assignments from the Attribute Bit Flags. assignments from the Attribute Bit Flags.
This document introduces a new Attribute Bit Flag: This document introduces a new Attribute Bit Flag:
o Bit number: TBD (10) o Bit number: TBD (10)
o Defining RFC: this I-D o Defining RFC: this I-D
o Name of bit: SRLG Collection Flag o Name of bit: SRLG Collection Flag
o The meaning of the SRLG Collection Flag is defined in this I-D o The meaning of the SRLG Collection Flag is defined in this I-D.
7.2. ROUTE_RECORD Object 7.2. ROUTE_RECORD Object
IANA has made the following assignments in the "Class Names, Class IANA has made the following assignments in the "Class Names, Class
Numbers, and Class Types" section of the "RSVP PARAMETERS" registry Numbers, and Class Types" section of the "RSVP PARAMETERS" registry
located at http://www.iana.org/assignments/rsvp-parameters. We located at http://www.iana.org/assignments/rsvp-parameters. We
request that IANA make assignments from the ROUTE_RECORD RFC 3209 request that IANA make assignments from the ROUTE_RECORD RFC 3209
[RFC3209] portions of this registry. [RFC3209] portions of this registry.
This document introduces a new RRO sub-object: This document introduces a new RRO sub-object:
Type Name Reference Type Name Reference
--------- ---------------------- --------- --------- ---------------------- ---------
TBD (34) SRLG sub-object This I-D TBD (34) SRLG sub-object This I-D
7.2.1. SRLG sub-object Flags
It is requested that the IANA ceates a registry to manage the space
of bit flags of the SRLG sub-object defined in this document. It is
requested that IANA makes assignments from the SRLG sub-object Flags.
This document introduces two new SRLG sub-object Flags.
+------------+-------------------+---------------+
| Bit Number | Name | Reference |
+------------+-------------------+---------------+
| 1 | SRLG-list edited | This document |
| 2 | Partial SRLG-list | This document |
+------------+-------------------+---------------+
7.3. Policy Control Failure Error subcodes 7.3. Policy Control Failure Error subcodes
IANA has made the following assignments in the "Error Codes and IANA has made the following assignments in the "Error Codes and
Globally-Defined Error Value Sub-Codes" section of the "RSVP Globally-Defined Error Value Sub-Codes" section of the "RSVP
PARAMETERS" registry located at http://www.iana.org/assignments/rsvp- PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-
parameters. We request that IANA make assignments from the Policy parameters. We request that IANA make assignments from the Policy
Control Failure Sub-Codes registry. Control Failure Sub-Codes registry.
This document introduces a new Policy Control Failure Error sub-code: This document introduces a new Policy Control Failure Error sub-code:
o Error sub-code: TBD (108) o Error sub-code: TBD (108)
o Defining RFC: this I-D o Defining RFC: this I-D
o Name of error sub-code: SRLG Recording Rejected o Name of error sub-code: SRLG Recording Rejected
o The meaning of the SRLG Recording Rejected error sub-code is o The meaning of the SRLG Recording Rejected error sub-code is
defined in this I-D defined in this I-D
8. Contributing Authors 8. Acknowledgements
Zafar Ali
Cisco Systems
zali@cisco.com
9. Acknowledgements
The authors would like to thank Igor Bryskin, Ramon Casellas, Lou The authors would like to thank Igor Bryskin, Ramon Casellas, Lou
Berger and Alan Davey for their useful comments and improvements to Berger and Alan Davey for their useful comments and improvements to
the document. the document.
10. Normative References 9. Normative References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[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 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
skipping to change at page 10, line 45 skipping to change at page 9, line 22
Authors' Addresses Authors' Addresses
Fatai Zhang (editor) Fatai Zhang (editor)
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: zhangfatai@huawei.com Email: zhangfatai@huawei.com
Dan Li
Huawei
F3-5-B RD Center
Bantian, Longgang District, Shenzhen 518129
P.R.China
Email: danli@huawei.com
Oscar Gonzalez de Dios (editor) Oscar Gonzalez de Dios (editor)
Telefonica I+D Telefonica Global CTO
Don Ramon de la Cruz Don Ramon de la Cruz
Madrid 28006 Madrid 28006
Spain Spain
Phone: +34 913328832 Phone: +34 913328832
Email: ogondio@tid.es Email: ogondio@tid.es
Dan Li
Huawei
F3-5-B RD Center
Bantian, Longgang District, Shenzhen 518129
P.R.China
Email: danli@huawei.com
Cyril Margaria Cyril Margaria
Nokia Siemens Networks SabenerStr. 44
St Martin Strasse 76 Munich 81547
Munich 81541
Germany Germany
Phone: +49 89 5159 16934 Phone: +49 89 5159 16934
Email: cyril.margaria@nsn.com Email: cyril.margaria@gmail.com
Matt Hartley Matt Hartley
Cisco Cisco
Email: mhartley@cisco.com Email: mhartley@cisco.com
Zafar Ali
Cisco
Email: zali@cisco.com
 End of changes. 25 change blocks. 
120 lines changed or deleted 57 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/