draft-ietf-bfd-intervals-05.txt   rfc7419.txt 
Internet Engineering Task Force N. Akiya Internet Engineering Task Force (IETF) N. Akiya
Internet-Draft M. Binderberger Request for Comments: 7419 M. Binderberger
Updates: RFC5880 (if approved) Cisco Systems Updates: 5880 Cisco Systems
Intended status: Informational G. Mirsky Category: Informational G. Mirsky
Expires: April 17, 2015 Ericsson ISSN: 2070-1721 Ericsson
October 14, 2014 December 2014
Common Interval Support in Bidirectional Forwarding Detection Common Interval Support in Bidirectional Forwarding Detection
draft-ietf-bfd-intervals-05
Abstract Abstract
Bidirectional Forwarding Detection (BFD) requires that messages are Bidirectional Forwarding Detection (BFD) requires that messages be
transmitted at regular intervals and provides a way to negotiate the transmitted at regular intervals and provides a way to negotiate the
interval used by BFD peers. Some BFD implementations may be interval used by BFD peers. Some BFD implementations may be
restricted to only support several interval values. When such BFD restricted to only support several interval values. When such BFD
implementations speak to each other, there is a possibility of two implementations speak to each other, there is a possibility of two
sides not being able to find a common value for the interval to run sides not being able to find a common value for the interval to run
BFD sessions. BFD sessions.
This document updates RFC 5880 by defining a small set of interval This document updates RFC 5880 by defining a small set of interval
values for BFD that we call "Common Intervals", and recommends values for BFD that we call "Common Intervals" and recommends
implementations to support the defined intervals. This solves the implementations to support the defined intervals. This solves the
problem of finding an interval value that both BFD speakers can problem of finding an interval value that both BFD speakers can
support while allowing a simplified implementation as seen for support while allowing a simplified implementation as seen for
hardware-based BFD. It does not restrict an implementation from hardware-based BFD. It does not restrict an implementation from
supporting more intervals in addition to the Common Intervals. supporting more intervals in addition to the Common Intervals.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on April 17, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7419.
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
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The problem with few supported intervals . . . . . . . . . . 3 2. The Problem with Few Supported Intervals . . . . . . . . . . 3
3. Well-defined, Common Intervals . . . . . . . . . . . . . . . 3 3. Well-Defined, Common Intervals . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Normative References . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Informative References . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5 Appendix A. Why Some Values Are in the Common Interval Set . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 5 Appendix B. Timer Adjustment with Non-identical Interval Sets . 6
Appendix A. Why some values are in the Common Interval set . . . 5 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Appendix B. Timer adjustment with non-identical interval sets . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The Bidirectional Forwarding Detection (BFD) standard [RFC5880] The Bidirectional Forwarding Detection (BFD) standard [RFC5880]
describes how to calculate the transmission interval and the describes how to calculate the transmission interval and the
detection time. It does not make any statement though how to solve a detection time. However, it does not make any statement about how to
situation where one BFD speaker cannot support the calculated value. solve a situation where one BFD speaker cannot support the calculated
In practice this may not been a problem as long as software- value. In practice, this may not have been a problem as long as
implemented timers have been used and as long as the granularity of software-implemented timers were used and as long as the granularity
such timers was small compared to the interval values being of such timers was small compared to the interval values being
supported, i.e. as long as the error in the timer interval was small supported, i.e. as long as the error in the timer interval was small
compared to 25 percent jitter. compared to 25 percent jitter.
In the meantime requests exist for very fast interval values, down to In the meantime, requests exist for very fast interval values, down
3.3msec for MPLS-TP. At the same time the requested scale for the to 3.3 msec for the MPLS Transport Profile (MPLS-TP). At the same
number of BFD sessions is increasing. Both requirements have driven time, the requested scale for the number of BFD sessions is
vendors to use Network Processors (NP), FPGAs or other hardware-based increasing. Both requirements have driven vendors to use Network
solutions to offload the periodic packet transmission and the timeout Processors (NP), Field Programmable Gate Arrays (FPGAs), or other
detection in the receive direction. A potential problem with this hardware-based solutions to offload the periodic packet transmission
hardware-based BFD is the granularity of the interval timers. and the timeout detection in the receive direction. A potential
Depending on the implementation only a few intervals may be problem with this hardware-based BFD is the granularity of the
supported, which can cause interoperability problems. This document interval timers. Depending on the implementation, only a few
proposes a set of interval values that should be supported by all intervals may be supported, which can cause interoperability
implementations. Details are laid out in the following sections. problems. This document proposes a set of interval values that
should be supported by all implementations. Details are laid out in
the following sections.
2. The problem with few supported intervals 2. The Problem with Few Supported Intervals
Let's assume vendor "A" supports 10msec, 100msec and 1sec interval Let's assume vendor "A" supports 10 msec, 100 msec, and 1 sec
timers in hardware. Vendor "B" supports every value from 20msec interval timers in hardware, and vendor "B" supports every value from
onward, with a granularity of 1msec. For a BFD session "A" tries to 20 msec onward, with a granularity of 1 msec. For a BFD session, "A"
set up the session with 10msec while "B" uses 20msec as the value for tries to set up the session with 10 msec while "B" uses 20 msec as
RequiredMinRxInterval and DesiredMinTxInterval. [RFC5880] describes the value for RequiredMinRxInterval and DesiredMinTxInterval. Rx and
that the negotiated value for Rx and Tx is 20msec. But system "A" is Tx are negotiated as described in [RFC5880], which is 20 msec in this
not able to support this. Multiple ways exist to resolve the dilemma case. However, system "A" is not able to support the 20 msec
but none of them is without problems. interval timer. Multiple ways exist to resolve the dilemma, but none
of them is without problems.
a. Realizing that it cannot support 20msec, system "A" sends out a a. Realizing that it cannot support 20 msec, system "A" sends out a
new BFD packet, advertising the next larger interval of 100msec new BFD packet advertising the next larger interval of 100 msec
with RequiredMinRxInterval and DesiredMinTxInterval. The new with RequiredMinRxInterval and DesiredMinTxInterval. The new
negotiated interval between "A" and "B" then is 100msec, which is negotiated interval between "A" and "B" is then 100 msec, which
supported by both systems. The problem though is that we moved is supported by both systems. However, the problem is that we
from the 10/20msec range to 100msec, which has far deviated from moved from the 10/20 msec range to 100 msec, which has far
operator expectations. deviated from operator expectations.
b. System "A" could violate [RFC5880] and use the 10msec interval b. System "A" could violate [RFC5880] and use the 10 msec interval
for the Tx direction. In the receive direction it could use an for the Tx direction. In the receive direction, it could use an
adjusted multiplier value M' = 2 * M to match the correct adjusted multiplier value M' = 2 * M to match the correct
detection time. Now beside the fact that we explicitly violate detection time. Now, in addition to the fact that we explicitly
[RFC5880] there may be the problem that system "B" drops up to violate [RFC5880], there may be the problem that system "B" drops
50% of the packets; this could be the case when "B" uses an up to 50% of the packets; this could be the case when "B" uses an
ingress rate policer to protect itself and the policer would be ingress rate policer to protect itself and the policer would be
programmed with an expectation of 20msec receive intervals. programmed with an expectation of 20 msec receive intervals.
The example above could be worse when we assume that system "B" can The example above could be worse when we assume that system "B" can
only support a few timer values itself. Let's assume "B" supports only support a few timer values itself. Let's assume "B" supports 20
"20msec", "300msec" and "1sec". If both systems would adjust their msec, 300 msec, and 1 sec. If both systems would adjust their
advertised intervals, then the adjustment ends at 1sec. The example advertised intervals, then the adjustment ends at 1 sec. The example
above could even be worse when we assume that system "B" can only above could even be worse when we assume that system "B" can only
support "50msec", "500msec" and "2sec". Even if both systems walk support 50 msec, 500 msec, and 2 sec. Even if both systems walk
their supported intervals, the two systems will never be able to through all of their supported intervals, the two systems will never
agree on a interval to run any BFD sessions. be able to agree on an interval to run any BFD sessions.
3. Well-defined, Common Intervals 3. Well-Defined, Common Intervals
The problem can be reduced by defining interval values that are The problem can be reduced by defining interval values that are
supported by all implementations. Then the adjustment mechanism supported by all implementations. Then, the adjustment mechanism
could find a commonly supported interval without deviating too much could find a commonly supported interval without deviating too much
from the original request. from the original request.
In technical terms the requirement is as follows: a BFD In technical terms, the requirement is as follows: a BFD
implementation should support all values in the set of Common implementation should support all values in the set of Common
Interval values which are equal to or larger than the fastest, i.e. Interval values that are equal to or larger than the fastest (i.e.,
lowest, interval the particular BFD implementation supports. lowest) interval the particular BFD implementation supports.
This document defines the set of Common Interval values to be: This document defines the set of Common Interval values to be: 3.3
3.3msec, 10msec, 20msec, 50msec, 100msec and 1sec. msec, 10 msec, 20 msec, 50 msec, 100 msec, and 1 sec.
In addition support for 10sec interval together with multiplier In addition, both a 10 sec interval and multiplier values up to 255
values up to 255 is recommended to support graceful restart. are recommended to support graceful restart.
The adjustment is always towards larger, i.e. slower, interval values The adjustment is always towards larger (i.e., slower) interval
when the initial interval proposed by the peer is not supported. values when the initial interval proposed by the peer is not
supported.
This document is not adding new requirements with respect to the This document is not adding new requirements with respect to the
precision with which a timer value must be implemented. Supporting precision with which a timer value must be implemented. Supporting
an interval value means to advertise this value in the an interval value means advertising this value in the
DesiredMinTxInterval and/or RequiredMinRxInterval field of the BFD DesiredMinTxInterval and/or RequiredMinRxInterval field of the BFD
packets and to provide timers that are reasonably close. [RFC5880] packets and providing timers that are reasonably close. [RFC5880]
defines safety margins for the timers by defining a jitter range. defines safety margins for the timers by defining a jitter range.
How is the "Common Interval" set used exactly? In the example above, How is the Common Interval set used exactly? In the example above,
vendor "A" has a fastest interval of 10msec and thus would be vendor "A" has a fastest interval of 10 msec and thus would be
required to support all intervals in the Common Interval set that are required to support all intervals in the Common Interval set that are
equal or larger than 10msec, i.e. it would support 10msec, 20msec, equal or larger than 10 msec, i.e., it would support 10 msec, 20
50msec, 100msec, 1sec. Vendor "B" has a fastest interval of 20msec msec, 50 msec, 100 msec, and 1 sec. Vendor "B" has a fastest
and thus would need to support 20msec, 50msec, 100msec and 1sec. As interval of 20 msec and thus would need to support 20 msec, 50 msec,
long as this requirement is met for the common set of values, then 100 msec, and 1 sec. As long as this requirement is met for the
both vendor "A" and "B" are free to support additional values outside common set of values, then both vendor "A" and "B" are free to
of the Common Interval set. support additional values outside of the Common Interval set.
4. IANA Considerations
RFC Ed.: RFC-editor please remove this section
No request to IANA.
5. Security Considerations 4. Security Considerations
This document does not introduce any additional security concerns. This document does not introduce any additional security concerns.
The security considerations described in the BFD documents, [RFC5880] The security considerations described in the BFD documents, [RFC5880]
and others, apply to devices implementing the BFD protocol, and others, apply to devices implementing the BFD protocol,
regardless of whether or not the Common Interval set is implemented. regardless of whether or not the Common Interval set is implemented.
6. Acknowledgements 5. References
We would like to thank Sylvain Masse and Anca Zamfir for bringing up
the discussion about the Poll sequence, and Jeffrey Haas helped
finding the fine line between "exact" and "pedantic".
7. References
7.1. Normative References 5.1. Normative References
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010. (BFD)", RFC 5880, June 2010,
<http://www.rfc-editor.org/info/rfc5880>.
7.2. Informative References 5.2. Informative References
[G.8013_Y.1731] [G.8013_Y.1731]
ITU-T G.8013/Y.1731, "ITU-T OAM functions and mechanisms International Telecommunications Union, "OAM functions and
for Ethernet based network", November 2013. mechanisms for Ethernet based networks", ITU-T
Recommendation G.8013/Y.1731, November 2013.
[GR-253-CORE] [GR-253-CORE]
Telcordia Technologies, Inc., "Synchronous Optical Network Telcordia Technologies, Inc., "Synchronous Optical Network
(SONET) Transport Systems: Common Generic Criteria", (SONET) Transport Systems: Common Generic Criteria",
October 2009. GR-253-CORE Issue 05, October 2009.
Appendix A. Why some values are in the Common Interval set Appendix A. Why Some Values Are in the Common Interval Set
The list of Common Interval values is trying to balance various The list of Common Interval values is trying to balance various
objectives. The list should not contain too many values as more objectives. The list should not contain too many values, as more
timers may increase the implementation costs. On the other hand less timers may increase the implementation costs. On the other hand,
values produces larger gaps and adjustment jumps. More values in the fewer values produces larger gaps and adjustment jumps. More values
lower interval range is thus seen as critical to support customer in the lower interval range are thus seen as critical to support
needs for fast detection in setups with multiple vendors. customer needs for fast detection in setups with multiple vendors.
o 3.3msec: required by MPLS-TP, adopting the detection time of o 3.3 msec: required by MPLS-TP, to support the defect detection
10msec from [GR-253-CORE]. time of 10 msec from [GR-253-CORE].
o 10msec: general consensus is to support 10msec. Multiple vendors o 10 msec: general consensus is to support 10 msec. Multiple
plan to or do already implement 10msec. vendors plan to or do already implement 10 msec.
o 20msec: basically avoids a larger gap in this critical interval o 20 msec: basically avoids a larger gap in this critical interval
region. Still allows 50-60msec detect and restore (with region. Still allows 50-60 msec detect and restore (with
multiplier of 2) and covers existing software-based multiplier of 2) and covers existing software-based
implementations. implementations.
o 50msec: widely deployed interval. Supporting this value reflects o 50 msec: widely deployed interval. Supporting this value reflects
reality of many BFD implementations today. the reality of many BFD implementations today.
o 100msec: similar to 10msec this value allows the reuse of o 100 msec: similar to 10 msec, this value allows the reuse of
[G.8013_Y.1731] implementations, especially hardware. It allows [G.8013_Y.1731] implementations, especially hardware. It supports
to support large scale of 9 x 100msec setups and would be a a large number of 100 msec sessions with multiplier 9 (9 x 100
replacement for 3 x 300msec configurations used by customers to msec), which could be replacing of 3 x 300 msec configurations
have a detection time slightly below 1sec for VoIP setups. used by customers to have a detection time slightly below 1 sec
for VoIP setups.
o 1sec: as mentioned in [RFC5880]. While the interval for Down o 1 sec: as mentioned in [RFC5880]. While the interval for Down
packets can be 1sec or larger this draft recommends to use exactly packets can be 1 sec or larger, this document recommends use of
1sec to avoid interoperability issues. exactly 1 sec to avoid interoperability issues.
The recommended value for large intervals is 10sec, allowing for a The recommended value for large intervals is 10 sec, allowing for a
timeout of 42.5 minutes with a multiplier of 255. This value is kept timeout of 42.5 minutes with a multiplier of 255. This value is kept
outside the Common Interval set as it is not required for normal BFD outside the Common Interval set, as it is not required for normal BFD
operations, which occur in the sub-second range. Instead the operations that occur in the sub-second range. Instead, the expected
expected usage is for graceful restart, if needed. usage is for graceful restart, if needed.
Appendix B. Timer adjustment with non-identical interval sets Appendix B. Timer Adjustment with Non-identical Interval Sets
[RFC5880] implicitly assumes that a BFD implementation can support [RFC5880] implicitly assumes that a BFD implementation can support
any timer value equal or above the advertised value. When a BFD any timer value equal to or above the advertised value. When a BFD
speaker starts a poll sequence then the peer must reply with the speaker starts a Poll Sequence, then the peer must reply with the
Final (F) bit set and adjust the transmit and detection timers Final (F) bit set and adjust the transmit and detection timers
accordingly. With contiguous software-based timers this is a valid accordingly. With contiguous software-based timers, this is a valid
assumption. Even in the case of a small number of supported interval assumption. Even in the case of a small number of supported interval
values this assumption holds when both BFD speakers support exactly values, this assumption holds when both BFD speakers support exactly
the same interval values. the same interval values.
But what happens when both speakers support intervals that are not But what happens when both speakers support intervals that are not
supported by the peer? An example is router "A" supporting the supported by the peer? An example is router "A" supporting the
Common Interval set plus 200msec while router "B" support the Common Common Interval set plus 200 msec, while router "B" supports the
Intervals plus 300msec. Assume both routers are configured and run Common Intervals plus 300 msec. Assume both routers are configured
at 50msec. Now router A is configured for 200msec. We know the and run at 50 msec. Now, router A is configured for 200 msec. We
result must be that both BFD speaker use 1sec timers but how do they know the result must be that both BFD speakers use 1 sec timers, but
reach this endpoint? how do they reach this endpoint?
First router A is sending a packet with 200msec. The P bit is set First, router A sends a packet with 200 msec. The P bit is set
according to [RFC5880]. The Tx timer stays at 50msec, the detection according to [RFC5880]. The Tx timer stays at 50 msec, the detection
timer is 3 * 200msec: timer is 3 * 200 msec:
(A) DesiredTx: 200msec, MinimumRx: 200msec, P-bit (A) DesiredTx: 200 msec, MinimumRx: 200 msec, P-bit
Tx: 50msec , Detect: 3 * 200msec Tx: 50 msec, Detect: 3 * 200 msec
Router B now must reply with an F bit. The problem is B is Router B now must reply with an F bit. The problem is B is
confirming timer values which it cannot support. The only setting to confirming timer values that it cannot support. The only setting to
avoid a session flap would be avoid a session flap would be
(B) DesiredTx: 300msec, MinimumRx: 300msec, F-bit (B) DesiredTx: 300 msec, MinimumRx: 300 msec, F-bit
Tx: 50msec , Detect: 3 * 300msec Tx: 50 msec, Detect: 3 * 300 msec
immediately followed by a P-bit packet as the advertised timer values immediately followed by a P-bit packet, as the advertised timer
have been changed: values have been changed:
(B) DesiredTx: 300msec, MinimumRx: 300msec, P-bit (B) DesiredTx: 300 msec, MinimumRx: 300 msec, P-bit
Tx: 50msec , Detect: 3 * 300msec Tx: 50 msec, Detect: 3 * 300 msec
This is not exactly what [RFC5880] states in section 6.8.7 about the This is not exactly what Section 6.8.7 of [RFC5880] states about the
transmission rate. On the other hand as we will see this state does transmission rate. On the other hand, as we will see, this state
not last for long. Router A would adjust its timers based on the does not last for long. Router A would adjust its timers based on
received Final bit the received Final bit:
(A) Tx: 200msec , Detect: 3 * 1sec (A) Tx: 200 msec, Detect: 3 * 1 sec
Router A is not supporting the proposed 300msec and would use 1sec Router A is not supporting the proposed 300 msec and would use 1 sec
instead for the detection time. It would then respond to the instead for the detection time. It would then respond to the
received Poll sequence from router B, using 1sec as router A does not received Poll Sequence from router B using 1 sec, as router A does
support the Max(200msec, 300msec): not support the Max(200 msec, 300 msec):
(A) DesiredTx: 1sec, MinimumRx: 1sec, F-bit (A) DesiredTx: 1 sec, MinimumRx: 1 sec, F-bit
Tx: 200msec , Detect: 3 * 1sec Tx: 200 msec, Detect: 3 * 1 sec
followed by its own Poll sequence as the advertised timer values have followed by its own Poll Sequence, as the advertised timer values
been changed: have been changed:
(A) DesiredTx: 1sec, MinimumRx: 1sec, P-bit (A) DesiredTx: 1 sec, MinimumRx: 1 sec, P-bit
Tx: 200msec , Detect: 3 * 1sec Tx: 200 msec, Detect: 3 * 1 sec
Router B would adjust its timers based on the received Final Router B would adjust its timers based on the received Final bit
(B) Tx: 300msec , Detect: 3 * 1sec (B) Tx: 300 msec , Detect: 3 * 1 sec
and would then reply to the Poll sequence from router A: and would then reply to the Poll Sequence from router A:
(B) DesiredTx: 300msec, MinimumRx: 300msec, F-bit (B) DesiredTx: 300 msec, MinimumRx: 300 msec, F-bit
Tx: 1sec , Detect: 3 * 1sec Tx: 1 sec, Detect: 3 * 1 sec
which finally makes router A adjusting its timers: which finally makes router A adjust its timers:
(A) Tx: 1sec , Detect: 3 * 1sec (A) Tx: 1 sec, Detect: 3 * 1 sec
In other words router A and B go through multiple poll sequences In other words, router A and B go through multiple Poll Sequences
until they reach a commonly supported interval value. Reaching such until they reach a commonly supported interval value. Reaching such
a value is guaranteed by this draft. a value is guaranteed by this document.
Acknowledgments
We would like to thank Sylvain Masse and Anca Zamfir for bringing up
the discussion about the Poll Sequence, and Jeffrey Haas for helping
find the fine line between "exact" and "pedantic".
Authors' Addresses Authors' Addresses
Nobo Akiya Nobo Akiya
Cisco Systems Cisco Systems
Email: nobo@cisco.com EMail: nobo@cisco.com
Marc Binderberger Marc Binderberger
Cisco Systems Cisco Systems
Email: mbinderb@cisco.com EMail: mbinderb@cisco.com
Greg Mirsky Greg Mirsky
Ericsson Ericsson
Email: gregory.mirsky@ericsson.com EMail: gregory.mirsky@ericsson.com
 End of changes. 76 change blocks. 
188 lines changed or deleted 186 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/