--- 1/draft-ietf-mpls-nodeid-subobject-03.txt	2006-02-05 00:42:00.000000000 +0100
+++ 2/draft-ietf-mpls-nodeid-subobject-04.txt	2006-02-05 00:42:00.000000000 +0100
@@ -1,21 +1,21 @@
 
                                     Jean Philippe Vasseur (Editor)
                                                       Zafar Ali
-                                                  Siva Sivabalan    Formatted:
+                                                    Siva Sivabalan
                                              Cisco Systems, Inc.
 
 IETF Internet Draft
 Expires: July, 2005
                                                           January, 2005
 
-              draft-ietf-mpls-nodeid-subobject-03.txt
+              draft-ietf-mpls-nodeid-subobject-04.txt
 
               Definition of an RRO node-id subobject
 
 Status of this Memo
 
 By submitting this Internet-Draft, I certify that any applicable patent
 or other IPR claims of which I am aware have been disclosed, and any of
 which I become aware will be disclosed, in accordance with RFC 3668.
 
 Working documents of the Internet Engineering Task Force (IETF), its
@@ -46,27 +46,28 @@
 (Area Border Router) or ASBR (Autonomous System Border Router)
 respectively. Such functionality has been listed as a clear requirement
 in [INTER-AREA-TE-REQS] and [INTER-AS-TE-REQS]. This document specifies
 the use of existing RRO IPv4 and IPv6 subobjects (with a new flag
 defined) to define the node-id subobject in order to solve this issue.
 Note that the MPLS Fast reroute mechanism mentioned in this document
 refers to the "Facility backup" MPLS TE Fast Reroute method.
 
 Table of content
 
-1. Terminology .................................................. 2
-2. Introduction ................................................. 3
-3. Signaling node-ids in RROs ................................... 5
-4. Finding Merge Point .......................................... 6
-5. Security Considerations ...................................... 6
-6. Intellectual Property Considerations ......................... 6
-7. Acknowledgments .............................................. 7
+1. Terminology ----------------------------- 2
+2. Introduction ---------------------------- 3
+3. Signaling node-ids in RROs -------------- 5
+4. Finding Merge Point --------------------- 6
+5. Security Considerations ----------------- 6
+6. Intellectual Property Considerations ---- 6
+7. Acknowledgments ------------------------- 7
+8. References ------------------------------ 7
 
 Conventions used in this document
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC-2119 [i].
 
 1.     Terminology
 
 LSR - Label Switch Router
@@ -146,21 +147,21 @@
 Assumptions:
 - A multi-area network made of three areas: 0, 1 and 2.
 - A fast reroutable TE LSP T1 (TE LSP signaled with the "local
 Protection desired" bit set in the SESSION-ATTRIBUTE object or the FRR
 object) from R0 to R3
 - A backup tunnel B1 from R1 to R2, not traversing ABR1, and following
 the R1-ABR3-R2 path. R1 reroutes any protected TE LSP traversing ABR1
 onto the backup tunnel B1 in case of ABR1's failure.
 
            <--- area 1 --><---area 0---><---area 2--->
-              R0-----R1-ABR1--R2------ABR2--------R3                     Formatted:
+              R0-----R1-ABR1--R2------ABR2--------R3
                      \        /
                       \ ABR3 /
 
 Figure 1: Use of Fast Reroute to protect against an ABR failure with
 MPLS Traffic Engineering Fast Reroute
 
 When T1 is first signaled, the PLR R1 needs to dynamically select an
 appropriate backup tunnel intersecting T1 on a downstream LSR. However,
 existing protocol mechanisms are not sufficient to unambiguously find
 the MP address in a network with inter-area or inter-AS traffic
@@ -312,20 +313,22 @@
 The IETF has been notified of intellectual property rights claimed in
 regard to some or all of the specification contained in this document.
 For more information consult the online list of claimed rights.
 
 7.     Acknowledgments
 
 We would like to acknowledge input and helpful comments from Carol
 Iturralde, Anca Zamfir, Reshad Rahman, Rob Goguen, Philip Matthews and
 Adrian Farrel.
 
+8. References
+
 Normative References
 
 [RFC2119]Bradner, S., "Key words for use in RFCs to Indicate
 Requirement Levels", BCP 14, RFC 2119, March 1997.
 
 [RFC3667]Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
 February 2004.
 
 [RFC3668]Bradner, S., Ed., "Intellectual Property Rights in IETF
 Technology", BCP 79, RFC 3668, February 2004.
@@ -389,21 +392,21 @@
 
 Siva Sivabalan
 Cisco Systems, Inc.
 2000 Innovation Drive
 Kanata, Ontario, K2K 3E8
 Canada
 msiva@cisco.com
 
 Full Copyright Statement
 
-Copyright (C) The Internet Society (2004).  This document is subject
+ Copyright (C) The Internet Society (2005).  This document is subject
 to the rights, licenses and restrictions contained in BCP 78, and
 except as set forth therein, the authors retain all their rights.
 
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 
 Vasseur, Ali and Sivabalan                                    8
 
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,