draft-ietf-rtgwg-ordered-fib-01.txt   draft-ietf-rtgwg-ordered-fib-02.txt 
Network Working Group Pierre Francois Network Working Group Pierre Francois
Internet-Draft Olivier Bonaventure Internet-Draft Olivier Bonaventure
Intended status: Standards Track Universite catholique de Louvain Intended status: Standards Track Universite catholique de Louvain
Expires: January, 2008 Mike Shand Expires: August 28, 2008 Mike Shand
Stewart Bryant Stewart Bryant
Stefano Previdi Stefano Previdi
Cisco Systems Cisco Systems
July, 2007 February 25, 2008
Loop-free convergence using oFIB Loop-free convergence using oFIB
draft-ietf-rtgwg-ordered-fib-01 draft-ietf-rtgwg-ordered-fib-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This draft describes a mechanism for use in conjunction with link This draft describes a mechanism for use in conjunction with link
state routing protocols which prevents the transient loops which state routing protocols which prevents the transient loops which
would otherwise occur during topology changes. It does this by would otherwise occur during topology changes. It does this by
correctly sequencing the FIB updates on the routers. correctly sequencing the FIB updates on the routers.
This mechanism can be used in the case of non-urgent link or node This mechanism can be used in the case of non-urgent link or node
shutdowns and restarts or link metric changes. It can also be used shutdowns and restarts or link metric changes. It can also be used
in conjunction with a FRR mechanism which converts a sudden link or in conjunction with a FRR mechanism which converts a sudden link or
node failure into a non-urgent topology change. This is possible node failure into a non-urgent topology change. This is possible
where a complete repair path is provided for all affected where a complete repair path is provided for all affected
destinations. destinations.
After a non-urgent topology change, each router computes a rank that After a non-urgent topology change, each router computes a rank that
defines the time at which it can safely update its FIB. A method for defines the time at which it can safely update its FIB. A method for
accelerating this loop-free convergence process by the use of accelerating this loop-free convergence process by the use of
completion messages is also described. completion messages is also described.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The required FIB update order . . . . . . . . . . . . . . . . 4
2.1. Single Link Events . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Link Down / Metric Increase . . . . . . . . . . . . . 4
2.1.2. Link Up / Metric Decrease . . . . . . . . . . . . . . 5
2.2. Multi-link events . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Router Down events . . . . . . . . . . . . . . . . . . 6
2.2.2. Router Up events . . . . . . . . . . . . . . . . . . . 6
2.2.3. Linecard Failure/Restoration Events . . . . . . . . . 6
3. Applying ordered FIB updates . . . . . . . . . . . . . . . . . 6
3.1. Deducing the topology change . . . . . . . . . . . . . . . 6
3.2. Deciding if ordered FIB updates applies . . . . . . . . . 7
4. Computation of the ordering . . . . . . . . . . . . . . . . . 8
4.1. Link or Router Down or Metric Increase . . . . . . . . . . 8
4.2. Link or Router Up or Metric Decrease . . . . . . . . . . . 8
5. Acceleration of Ordered Convergence . . . . . . . . . . . . . 9
5.1. Construction of the waiting list and notification list . . 9
5.1.1. Down events . . . . . . . . . . . . . . . . . . . . . 10
5.1.2. Up Events . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Format of Completion Messages . . . . . . . . . . . . . . 10
6. Fall back to Conventional Convergence . . . . . . . . . . . . 10
7. oFIB state machine . . . . . . . . . . . . . . . . . . . . . . 11
7.1. OFIB_STABLE . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. OFIB_HOLDING_DOWN . . . . . . . . . . . . . . . . . . . . 12
7.3. OFIB_HOLDING_UP . . . . . . . . . . . . . . . . . . . . . 13
7.4. OFIB_ONGOING . . . . . . . . . . . . . . . . . . . . . . . 14
7.5. OFIB_ABANDONED . . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
With link-state protocols [1][2], each time the network topology With link-state protocols [1][2], each time the network topology
changes, some routers need to modify their Forwarding Information changes, some routers need to modify their Forwarding Information
Base (FIB) to take into account the new topology. Each topology Base (FIB) to take into account the new topology. Each topology
change causes a convergence phase. During this phase, routers may change causes a convergence phase. During this phase, routers may
transiently have inconsistent FIBs, which may lead to packet loops transiently have inconsistent FIBs, which may lead to packet loops
and losses, even if the reachability of the destinations is not and losses, even if the reachability of the destinations is not
compromised after the topology change. Packet losses and transient compromised after the topology change. Packet losses and transient
loops can also occur in the case of a link down event implied by a loops can also occur in the case of a link down event implied by a
skipping to change at page 7, line 23 skipping to change at page 7, line 41
If an event is received within the hold down period which does NOT If an event is received within the hold down period which does NOT
reference the common router (R) then in this version of the reference the common router (R) then in this version of the
specification normal convergence is invoked immediately (see specification normal convergence is invoked immediately (see
Section 6). Section 6).
The sudden failure of a link or a set of links that are not protected The sudden failure of a link or a set of links that are not protected
using a FRR mechanism must be processed using the conventional mode using a FRR mechanism must be processed using the conventional mode
of operation. of operation.
In summary an event can be dealt with an ordered FIB process iif the In summary an ordered FIB process is applicable iif the set of link
set of link state notifications received between the first event and state notifications received between the first event and the hold
the hold down period reference a common router R, and one of the down period reference a common router R, and one of the following
following assertions is verified : assertions is verified :
. The set of notifications refer to link down events concerning . The set of notifications refer to link down events concerning
protected links and metric increase events protected links and metric increase events
. The set of notifications refer to link up events and metric . The set of notifications refer to link up events and metric
decrease events. decrease events.
4. Calculation of the ordering 4. Computation of the ordering
This section describes how the required ordering is calculated. This section describes how the required ordering is computed.
4.1. Link or Router Down or Metric Increase 4.1. Link or Router Down or Metric Increase
To respect the proposed ordering, routers compute a rank that will be To respect the proposed ordering, routers compute a rank that will be
used to determine the time at which they are permitted to perform used to determine the time at which they are permitted to perform
their FIB update. In the case of a failure event rooted at router Y their FIB update. In the case of a failure event rooted at router Y
or an increase of the metric of link X->Y, router R computes the or an increase of the metric of link X->Y, router R computes the
reverse Shortest Path Tree in the topology before the failure reverse Shortest Path Tree in the topology before the failure
(rSPT_OLD) rooted at Y. This rSPT gives the shortest paths to reach Y (rSPT_OLD) rooted at Y. This rSPT gives the shortest paths to reach Y
before the failure. The branch of the reverse SPT that is below R before the failure. The branch of the reverse SPT that is below R
skipping to change at page 8, line 50 skipping to change at page 9, line 22
5. Acceleration of Ordered Convergence 5. Acceleration of Ordered Convergence
The mechanism described above is conservative, and hence may be The mechanism described above is conservative, and hence may be
relatively slow. The purpose of this section is to describe a method relatively slow. The purpose of this section is to describe a method
of accelerating the controlled convergence in such a way that ordered of accelerating the controlled convergence in such a way that ordered
loop-free convergence is still guaranteed. loop-free convergence is still guaranteed.
In many cases a router will complete its required FIB changes in a In many cases a router will complete its required FIB changes in a
time much shorter than MAX_FIB and in many other cases, a router will time much shorter than MAX_FIB and in many other cases, a router will
not have to perform any FIB changes at all. not have to perform any FIB change at all.
This section describes the use of completion messages to speed up the This section describes the use of completion messages to speed up the
convergence by providing a means for a router to inform those routers convergence by providing a means for a router to inform those routers
waiting for it, that it has completed any required FIB changes. When waiting for it, that it has completed any required FIB changes. When
a router has been advised of completion by all the routers for which a router has been advised of completion by all the routers for which
it is waiting, it can safely update its own FIB without further it is waiting, it can safely update its own FIB without further
delay. In most cases this can result in a sub-second re-convergence delay. In most cases this can result in a sub-second re-convergence
time comparable with that of normal convergence. time comparable with that of normal convergence.
Routers maintain a waiting list of the neighbours from which a Routers maintain a waiting list of the neighbours from which a
skipping to change at page 10, line 29 skipping to change at page 11, line 5
. Node ID of the far end of the link . Node ID of the far end of the link
. Old Metric . Old Metric
. New Metric . New Metric
6. Fall back to Conventional Convergence 6. Fall back to Conventional Convergence
In circumstances where a router detects that it is dealing with In circumstances where a router detects that it is dealing with
incomplete or inconsistent link state information, or when a further incomplete or inconsistent link state information, or when a further
topology event is received before completion of the current ordered topology event is received before completion of the current ordered
FIB update process it may be expedient to abandon the controlled FIB update process it may be expedient to abandon the controlled
convergence process and revert to conventional convergence by convergence process. Fall back mechanisms are investigated in [11].
immediately expiring all the associated ranking timers. This The state machine defined in this version of the draft does not make
mechanism is similar to the one described in section 3.1 of [6]. an assumption on which fall back mechanism will be used.
Abandoning the controlled convergence process may be instigated by 7. oFIB state machine
any router within the network.
7. Acknowledgments An ofib capable router maintains an ofib state value which can be one
of : OFIB_STABLE, OFIB_HOLDING_DOWN, OFIB_HOLDING_UP, OFIB_ABANDONED,
OFIB_ONGOING.
An ofib capable router maintains a timer, Hold_down_timer. An ofib
capable router is configured with a value refered to as
HOLD_DOWN_DURATION. This configuration can be performed manually or
using [9].
An ofib capable router maintains a timer, rank_timer.
7.1. OFIB_STABLE
OFIB_STABLE is the state of a router which is not currently involved
in any convergence process. This router is ready to process an event
by applying ofib.
EVENT : Reception of a link-state packet describing an event of the
type link X--Y down or metric increase to be processed using oFIB.
ACTION : Set state to OFIB_HOLDING_DOWN. Start Hold_down_timer.
ofib_current_common_set = {X,Y}. Compute rank with respect to the
event, as defined in Section 4. Store Waiting List and Notification
List for X--Y obtained from the rank computation.
EVENT : Reception of a link-state packet describing an event of the
type link X--Y up or metric decrease which to be processed using
oFIB.
ACTION :
Set state to OFIB_HOLDING_UP.
Start Hold_down_timer.
ofib_current_common_set = {X,Y}
Compute rank with respect to the event, as defined in section
Section 4 .
Store Waiting List and Notification List for X--Y obtained from
the rank computation.
7.2. OFIB_HOLDING_DOWN
OFIB_HOLDING_DOWN is the state of a router that is collecting a set
of link down or metric increase link-state packets to be processed
together using controlled convergence.
EVENT : Reception of a link-state packet describing an event of the
type link up or metric decrease which in itself can be processed
using oFIB.
ACTION :
Set state to OFIB_ABANDONED.
Reset Hold_down_timer.
Trigger AAH mechanism
EVENT : Reception of a link-state packet describing an event of the
type link A--B down or metric increase which in itself can be
processed using oFIB.
ACTION :
ofib_current_common_set =
intersection(ofib_current_common_set,{A,B}).
If ofib_current_common_set is empty, then there is no longer a
node in common in all the pending link-state changes.
Set state to OFIB_ABANDONED
Reset Hold_down_timer
Trigger AAH mechanism.
If ofib_current_common set is not empty, update waiting list and
notification list as defined in Section 4. Note that in the
case of a single link event, the link-state packet received when
the router is in this state describes the state change of the
other direction of the link, hence no changes will be made to
the waiting and notification lists.
EVENT : Hold_down_timer expires.
ACTION :
Set state to OFIB_ONGOING.
Start rank_timer with computed rank.
EVENT : Reception of a completion message
ACTION : Remove the sender from waiting list associated with the
event identified in the completion message.
7.3. OFIB_HOLDING_UP
OFIB_HOLDING_UP is the state of a router that is collecting a set of
link up or metric decrease link-state packets to be processed
together using controlled convergence.
EVENT : Reception of a link-state packet describing an event of the
type link down or metric increase to be processed using oFIB.
ACTION :
Set state to OFIB_ABANDONED.
Reset Hold_down_timer.
Trigger AAH mechanism.
EVENT : Reception of a link-state packet describing an event of the
type link A--B up or metric decrease to be processed using oFIB.
ACTION :
ofib_current_common_set =
intersection(ofib_current_common_set,{A,B}).
If ofib_current_common_set is empty, then there is no longer a
common node in the set of pending link-state changes.
Set state to OFIB_ABANDONED.
Reset Hold_down_timer.
Trigger AAH mechanism.
If ofib_current_common set is not empty, update waiting list and
notification list as defined in Section 4. Note that in the
case of a single link event, the link-state packet received when
the router is in this state describes the state change of the
other direction of the link, hence no changes will be made to
the waiting and notification lists.
EVENT : Reception of a completion message
ACTION : Remove the sender from the waiting list associated with the
event identified in the completion message.
EVENT : Hold_down_timer expires.
ACTION :
Set state to OFIB_ONGOING.
Start rank_timer with computed rank.
7.4. OFIB_ONGOING
OFIB_ONGOING is the state of a router that is applying the ordering
mechanism w.r.t. the set of LSP collected when in OFIB_HOLDING_DOWN
or OFIB_HOLDING_UP state.
EVENT : rank_timer expires or waiting list becomes empty.
ACTION :
Perform FIB updates according to the change.
Send completion message to each member of the notification list.
Set State to OFIB_STABLE.
EVENT : Reception of a completion message
ACTION : Remove the sender from the waiting list.
EVENT : Reception of a link-state packet describing a link state
change event.
ACTION :
Set state to OFIB_ABANDONED.
Trigger AAH.
Start Hold_down_timer.
7.5. OFIB_ABANDONED
OFIB_ABANDONED is the state of a router that has fallen back to fast
convergence due to the reception of link-state packets that cannot be
dealt together using oFIB.
EVENT : Reception of a link-state packet describing a link-state
change event.
ACTION : Trigger AAH, reset Hold_down_timer.
EVENT : Hold_down_timer expires.
ACTION : Set state to OFIB_STABLE
8. Acknowledgments
We would like to thank Clarence Filsfils and Jean-Philippe Vasseur We would like to thank Clarence Filsfils and Jean-Philippe Vasseur
for their useful suggestions and comments. for their useful suggestions and comments.
8. References 9. References
[1] "Intermediate system to Intermediate system routeing [1] "Intermediate system to Intermediate system routeing
information exchange protocol for use in conjunction with the information exchange protocol for use in conjunction with the
Protocol for providing the Connectionless mode Network Service Protocol for providing the Connectionless mode Network Service
(ISO 8473). ISO/IEC 10589:2002, Second Edition". (ISO 8473). ISO/IEC 10589:2002, Second Edition".
[2] J. Moy, "OSPF Version 2", RFC 2328, April 1998. [2] J. Moy, "OSPF Version 2", RFC 2328, April 1998.
[3] M. Shand and S. Bryant, "IP Fast Reroute Framework", [3] M. Shand and S. Bryant, "IP Fast Reroute Framework",
draft-ietf-rtgwg-ipfrr-framework-07.txt (work in progress), draft-ietf-rtgwg-ipfrr-framework-07.txt (work in progress),
June 2007. June 2007.
[4] O. Bonaventure, P. Francois, M. Shand, and S. Previdi, "IP Fast [4] O. Bonaventure, P. Francois, and S. Previdi, "ISIS extensions
Reroute Framework", draft-bonaventure-isis-ordered-00.txt (work for ordered FIB updates", draft-bonaventure-isis-ordered-00.txt
in progress), Feb 2006. (work in progress), Feb 2006.
[5] S. Bryant and M. Shand, "Applicability of Loop-free [5] S. Bryant and M. Shand, "Applicability of Loop-free
Convergence", draft-bryant-shand-lf-applicability-03.txt (work Convergence", draft-bryant-shand-lf-applicability-03.txt (work
in progress), May 2007. in progress), May 2007.
[6] A. Zinin, "Analysis and Minimization of Microloops in Link- [6] A. Zinin, "Analysis and Minimization of Microloops in Link-
state Routing Protocols", state Routing Protocols",
draft-ietf-rtgwg-microloop-analysis-01.txt (work in progress), draft-ietf-rtgwg-microloop-analysis-01.txt (work in progress),
Oct 2005. Oct 2005.
[7] P. Francois and O. Bonaventure, "Avoiding transient loops [7] P. Francois and O. Bonaventure, "Avoiding transient loops
during IGP convergence in IP Networks", in Proceedings of during IGP convergence in IP Networks", in IEEE/ACM
INFOCOM'05, http://inl.info.ucl.ac.be/publications/ Transactions on Networking,
avoiding-transient-loops-during-convergence-link-state-routing- http://inl.info.ucl.ac.be/publications, December 2007.
protocols, March 2005.
[8] P. Pan et al., "Fast Reroute Extensions to RSVP-TE for LSP [8] P. Pan et al., "Fast Reroute Extensions to RSVP-TE for LSP
Tunnels", RFC 4090. Tunnels", RFC 4090.
[9] A. Atlas, S. Bryant, and M. Shand, "Synchronization of Loop [9] S. Bryant, A. Atlas, and M. Shand, "Synchronisation of Loop
Free Timer Values", draft-atlas-bryant-shand-lf-timers-03.txt Free Timer Values", draft-atlas-bryant-shand-lf-timers-03 (work
(work in progress), Jul 2007. in progress), July 2007.
[10] P. Francois, C. Filsfils, J. Evans, and O. Bonaventure, [10] P. Francois, C. Filsfils, J. Evans, and O. Bonaventure,
"Achieving sub-second IGP convergence in large IP Networks", "Achieving sub-second IGP convergence in large IP Networks",
in ACM SIGCOMM Computer Communication Review, in ACM SIGCOMM Computer Communication Review,
http://portal.acm.org/citation.cfm?id=1070873.1070877, http://portal.acm.org/citation.cfm?id=1070873.1070877,
July 2005. July 2005.
Appendix A. General SRLG Case [11] S. Bryant, P. Francois, and M. Shand, "Mechanisms for safely
abandoning loop-free convergence (AAH)", February 2008.
This appendix describes the operation of oFIB when multiple link
events which DO NOT have a node in common occur at approximately the
same time. The covered events are the failure of a set of links and
the restoration of a set of links. Note that for the case of a
sudden SRLG failure, it is assumed that this is fully protected by a
Fast Reroute mechanism, thus converting it into an non-urgent event.
In order to be applicable, this solution requires that routers have
the same, consistent, view of the set of events. This can be
achieved by means of the hold down mechanism described in Section 3.1
and [6].
A.1. SRLG Down Events
A.1.1. Determining the ordering
Consider the case where there are two failing components F and G. In
the general case, the ranking for any given router R will be
different for destinations reached through F and those reached
through G. R must therefore partition its FIB changes into a number
of destination sets. In the worst-case, the number of destination
sets will equal the number of failing links.
Router R computes the ranks associated with each of the failing
links. It does this by applying the same algorithm as for single
link down events. The rank at which a router R must update its FIB
for a destination D is equal to the minimum rank among the ranks of
the links that R uses to reach the destination D.
A.1.2. Completion messages
As described above, a router R computes the Waiting and Notification
lists associated with each of the failing links when it determines
the ranking.
When R has received a completion message from all the members of the
waiting list associated with a link, it is allowed to update its FIB
for all the destinations that it was previously reaching via that
link.
A router will send a completion message to the members of the
Notification list for a given link once it has updated its FIB for
all the prefixes that it reached via the link.
A.2. SRLG Up Events
A.2.1. Determining the ordering
Consider the case where a set of links is brought up in the network.
R computes the rank associated with each link, by the means of its
renewed SPT. The rank at which R must update its FIB for a
destination D is the maximum rank among the ranks of the links that
it will use to reach D.
A.2.2. Completion messages
As described above, a router R will compute the Waiting List and
Notification List associated with each of the links that come up in
the network.
When R has received completion messages for the links that it will
use to reach a destination D, it can safely update its FIB for D.
When R has updated its FIB for all the destinations that it reaches
via a link, it will send a completion message for this link towards
the neighbors that are not in its Waiting List for this link.
Authors' Addresses Authors' Addresses
Pierre Francois Pierre Francois
Universite catholique de Louvain Universite catholique de Louvain
Place Ste Barbe, 2 Place Ste Barbe, 2
Louvain-la-Neuve 1348 Louvain-la-Neuve 1348
BE BE
Email: francois@info.ucl.ac.be URI: http://inl.info.ucl.ac.be/
Olivier Bonaventure Olivier Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
Place Ste Barbe, 2 Place Ste Barbe, 2
Louvain-la-Neuve 1348 Louvain-la-Neuve 1348
BE BE
Email: bonaventure@info.ucl.ac.be URI: http://inl.info.ucl.ac.be/
Mike Shand Mike Shand
Cisco Systems Cisco Systems
Green Park, 250, Longwater Avenue, Green Park, 250, Longwater Avenue,
Reading RG2 6GB Reading RG2 6GB
UK UK
Email: mshand@cisco.com Email: mshand@cisco.com
Stewart Bryant Stewart Bryant
Cisco Systems Cisco Systems
Green Park, 250, Longwater Avenue, Green Park, 250, Longwater Avenue,
Reading RG2 6GB Reading RG2 6GB
UK UK
Email: stbryant@cisco.com Email: stbryant@cisco.com
Stefano Previdi Stefano Previdi
Cisco Systems Cisco Systems
skipping to change at page 15, line 7 skipping to change at page 17, line 7
Stefano Previdi Stefano Previdi
Cisco Systems Cisco Systems
Via Del Serafico 200 Via Del Serafico 200
00142 Roma 00142 Roma
Italy Italy
Email: sprevidi@cisco.com Email: sprevidi@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 22 change blocks. 
100 lines changed or deleted 242 lines changed or added

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