draft-ietf-ccamp-rsvp-te-srlg-collect-00.txt   draft-ietf-ccamp-rsvp-te-srlg-collect-01.txt 
Network Working Group F. Zhang, Ed. Network Working Group F. Zhang, Ed.
Internet-Draft D. Li Internet-Draft D. Li
Intended status: Standards Track Huawei Intended status: Standards Track Huawei
Expires: December 28, 2012 O. Gonzalez de Dios, Ed. Expires: April 25, 2013 O. Gonzalez de Dios, Ed.
Telefonica I+D Telefonica I+D
C. Margaria C. Margaria
Nokia Siemens Networks Nokia Siemens Networks
June 26, 2012 M. Hartley
Cisco
October 22, 2012
RSVP-TE Extensions for Collecting SRLG Information RSVP-TE Extensions for Collecting SRLG Information
draft-ietf-ccamp-rsvp-te-srlg-collect-00 draft-ietf-ccamp-rsvp-te-srlg-collect-01
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 37 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 December 28, 2012. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 16 skipping to change at page 2, line 18
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . 4
3.2. SRLG sub-object . . . . . . . . . . . . . . . . . . . . . . 4 3.2. SRLG sub-object . . . . . . . . . . . . . . . . . . . . . . 4
4. Signaling Procedures . . . . . . . . . . . . . . . . . . . . . 5 4. Signaling Procedures . . . . . . . . . . . . . . . . . . . . . 5
4.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . . 5 4.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . . 5
4.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Manageability Considerations . . . . . . . . . . . . . . . . . 6 5. Manageability Considerations . . . . . . . . . . . . . . . . . 7
5.1. Policy Configuration . . . . . . . . . . . . . . . . . . . 6 5.1. Policy Configuration . . . . . . . . . . . . . . . . . . . 7
5.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . . 6 5.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . . 7 7.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . . 8
7.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . . 7 7.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 10. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
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 3, line 28 skipping to change at page 3, line 28
This document provides an automatic mechanism to collect the SRLG for This document provides an automatic mechanism to collect the SRLG for
the TE link formed by a LSP. Note that how to use the collected SRLG the TE link formed by a LSP. Note that how to use the collected SRLG
information is out of scope of this document information is out of scope of this document
2. RSVP-TE Requirements 2. RSVP-TE Requirements
2.1. SRLG Collection Indication 2.1. SRLG Collection Indication
The head nodes of the LSP must be capable of indicating whether the The head nodes of the LSP must be capable of indicating whether the
SRLG information of the LSP should be collected during the signaling SRLG information of the LSP should be collected during the signaling
procedure of setting up an LSP. procedure of setting up an LSP. SRLG information should not be
collected without an explicit request for it being made by the head
node.
2.2. SRLG Collection 2.2. SRLG Collection
The SRLG information can be collected during the setup of an LSP. If requested, the SRLG information should be collected during the
Then the endpoints of the LSP can get the SRLG information and use it setup of an LSP. The endpoints of the LSP may use the collected SRLG
for routing, sharing and TE link configuration purposes. information and use it for routing, sharing and TE link configuration
purposes.
2.3. SRLG Update 2.3. SRLG Update
When the SRLG information changes, the endpoints of the LSP need to When the SRLG information of an existing LSP for which SRLG
be capable of updating the SRLG information of the path. It means information was collected during signaling changes, the relevant
that the signaling should be capable of updating the newly SRLG nodes of the LSP must be capable of updating the SRLG information of
information to the endpoints. the LSP. This means that that the signaling procedure must be
capable of updating the new SRLG information.
3. RSVP-TE Extensions (Encoding) 3. RSVP-TE Extensions (Encoding)
3.1. SRLG Collection Flag 3.1. SRLG Collection Flag
In order to indicate nodes that SRLG collection is desired, this In order to indicate nodes that SRLG collection is desired, this
document defines a new flag in the Attribute Flags TLV, which is document defines a new flag in the Attribute Flags TLV, which is
carried in an LSP_REQUIRED_ATTRIBUTES Object: carried in an LSP_REQUIRED_ATTRIBUTES Object: [Editor's note:
LSP_ATTRIBUTES Object is also under consideration]
o Bit Number (to be assigned by IANA, recommended bit zero): SRLG o Bit Number (to be assigned by IANA, recommended bit zero): SRLG
Collection flag 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 head and tail node along the setup of the should be reported to the head and tail node along the setup of the
LSP. LSP.
The rules of the processing of the Attribute Flags TLV are not The rules of the processing of the Attribute Flags TLV are not
skipping to change at page 4, line 25 skipping to change at page 4, line 31
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 | | Type | Length | Reserved | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 SRLG Id
The 32-bit identifier of the SRLG. The 32-bit identifier of the SRLG.
Reserved Reserved
This field is reserved. It SHOULD be set to zero on transmission and This field is reserved. It SHOULD be set to zero on transmission and
MUST be ignored on receipt. MUST be ignored on receipt.
The rules of the processing of the LSP_REQUIRED_ATTRIBUTES Object and The rules of the processing of the LSP_REQUIRED_ATTRIBUTES Object and
ROUTE_RECORD Object are not changed. ROUTE_RECORD Object are not changed.[Editor's note: The rules of
processing LSP_ATTRIBUTES Object (which is under consideration) are
also 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
SRLG Collection Flag in the Attribute Flags TLV which can be carried SRLG Collection Flag in the Attribute Flags TLV which can be carried
in an LSP_REQUIRED_ATTRIBUTES Object. in an LSP_REQUIRED_ATTRIBUTES Object.
When a node receives a Path message which carries an When a node receives a Path message which carries an
LSP_REQUIRED_ATTRIBUTES Object and the SRLG Collection Flag is set, LSP_REQUIRED_ATTRIBUTES Object and the SRLG Collection Flag is set,
if local policy determines that the SRLG information should not be if local policy determines that the SRLG information should not be
provided to the endpoints, it must return a PathErr message to reject provided to the endpoints, it must return a PathErr message to reject
the Path message. Otherwise, it must add an SRLG sub-object to the the Path message. Otherwise, it must add an SRLG sub-object to the
RRO to carry the local SRLG information. Then it forwards the Path RRO to carry the local SRLG information. Then it forwards the Path
message to the next node in the downstream direction. message to the next node in the downstream direction.
[Editor's note: It is under consideration that with the Path message
carries an LSP_REQUIRED_ATTRIBUTES Object and the SRLG Collection
Flag is set, if local policy determines that the SRLG information
should not be provided to the endpoints, the Path message should not
rejected and the SRLG sub-object must not added]
Following the steps described above, the intermediate nodes of the Following the steps described above, the intermediate nodes of the
LSP can collect the SRLG information in the RRO during the forwarding LSP can collect the SRLG information in the RRO during the forwarding
of the Path message hop by hop. When the Path message arrives at the of the Path message hop by hop. When the Path message arrives at the
tail node, the tail node can get the SRLG information from the RRO. tail node, the tail node can get the SRLG information from the RRO.
Before the Resv message is sent to the upstream node, the tail node Before the Resv message is sent to the upstream node, the tail node
adds an SRLG sub-object to the RRO. The collected SRLG information adds an SRLG sub-object to the RRO. The collected SRLG information
can be carried in the SRLG sub-object. Therefore, during the can be carried in the SRLG sub-object. Therefore, during the
forwarding of the Resv message in the upstream direction, the SRLG forwarding of the Resv message in the upstream direction, the SRLG
information is not needed to be collected hop by hop. information is not needed to be collected hop by hop.
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 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 RRO to remove the route information (e.g. node, interface identifier
information) before forwarding it due to some reasons (e.g. information) before forwarding it due to some reasons
confidentiality or reduce the size of RRO), but the SRLG information (e.g.confidentiality or reduce the size of RRO). A node MAY edit
should be retained if it is desirable for the endpoints of the LSP. 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.
[Editor's note: Two behaviors are under consideration: using
LSP_REQUIRED_ATTRIBUTES the collection is mandatory, while using
LSP_ATTRIBUTES the collection is desired, but not mandatory]
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. 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
SRLG change should be suppressed or would result in no change to the
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. be exposed to the nodes outside the domain or layer network, or
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.
o If the SRLG IDs must not be exposed to the nodes outside of the o If the SRLG IDs must not be exposed to the nodes outside of the
domain or specific layer network by policy, the border node must domain or specific layer network by policy, the border node must
reject the Path message desiring SRLG recording and send a PathErr reject the Path message desiring SRLG recording and send a PathErr
message with the defined error code 'Policy Control message with the defined error code 'Policy Control
Failure'/'Inter-domain policy failure'. Failure'/'Inter-domain policy failure'. [Editor's note: This last
statement may be removed in next versions and do not impose such
rejection.]
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
skipping to change at page 7, line 6 skipping to change at page 8, line 4
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
TBD. TBD.
7. IANA Considerations 7. IANA Considerations
7.1. RSVP Attribute Bit Flags 7.1. RSVP Attribute Bit Flags
The IANA has created a registry and manages the space of attributes The IANA has created a registry and manages the space of attributes
bit flags of Attribute Flags TLV as described in section 11.3 of bit flags of Attribute Flags TLV as described in section 11.3 of
[RFC5420]. It is requested that the IANA makes assignments from the [RFC5420]. It is requested that the IANA makes assignments from the
Attribute Bit Flags. Attribute Bit Flags.
This document introduces a new Attribute Bit Flag: This document introduces a new Attribute Bit Flag:
o Bit number: TBD (0) 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 Attribute Flags TLV on a Path is defined in o The meaning of the Attribute Flags TLV on a Path is defined in
this I-D this I-D
7.2. ROUTE_RECORD Object 7.2. ROUTE_RECORD Object
skipping to change at page 7, line 39 skipping to change at page 8, line 36
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
8. Acknowledgements 8. Contributing Authors
Zafar Ali
Cisco Systems
zali@cisco.com
9. Acknowledgements
The authors would like to thank Igor Bryskin, Ramon Casellas and Lou The authors would like to thank Igor Bryskin, Ramon Casellas and Lou
Berger for their useful comments to the document. Berger for their useful comments to the document.
9. Normative References 10. 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.
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005. (GMPLS)", RFC 4202, October 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
skipping to change at page 8, line 39 skipping to change at page 10, line 4
Email: zhangfatai@huawei.com Email: zhangfatai@huawei.com
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
Phone: Phone:
Email: danli@huawei.com Email: danli@huawei.com
Oscar Gonzalez de Dios (editor) Oscar Gonzalez de Dios (editor)
Telefonica I+D Telefonica I+D
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
Cyril Margaria Cyril Margaria
Nokia Siemens Networks Nokia Siemens Networks
St Martin Strasse 76 St Martin Strasse 76
Munich, 81541 Munich, 81541
Germany Germany
Phone: +49 89 5159 16934 Phone: +49 89 5159 16934
Email: cyril.margaria@nsn.com Email: cyril.margaria@nsn.com
Matt Hartley
Cisco
Phone:
Email: mhartley@cisco.com
 End of changes. 27 change blocks. 
37 lines changed or deleted 89 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/