< draft-ietf-bfd-multipoint-active-tail-05.txt   draft-ietf-bfd-multipoint-active-tail-06.txt >
Internet Engineering Task Force D. Katz Internet Engineering Task Force D. Katz
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track D. Ward Intended status: Standards Track D. Ward
Expires: June 14, 2018 Cisco Systems Expires: June 22, 2018 Cisco Systems
S. Pallagatti, Ed. S. Pallagatti, Ed.
Individual Contributor Individual Contributor
December 11, 2017 G. Mirsky, Ed.
ZTE Corp.
December 19, 2017
BFD Multipoint Active Tails. BFD Multipoint Active Tails.
draft-ietf-bfd-multipoint-active-tail-05 draft-ietf-bfd-multipoint-active-tail-06
Abstract Abstract
This document describes active tail extensions to the Bidirectional This document describes active tail extensions to the Bidirectional
Forwarding Detection (BFD) protocol for multipoint and multicast Forwarding Detection (BFD) protocol for multipoint and multicast
networks. Comments on this draft should be directed to rtg- networks.
bfd@ietf.org.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 June 14, 2018. This Internet-Draft will expire on June 22, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 21 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Multipoint Client Session . . . . . . . . . . . . . . . . 4 3.1. Multipoint Client Session . . . . . . . . . . . . . . . . 4
3.2. Multipoint Client Session Failure . . . . . . . . . . . . 4 3.2. Multipoint Client Session Failure . . . . . . . . . . . . 5
3.3. State Variables . . . . . . . . . . . . . . . . . . . . . 5 3.3. State Variables . . . . . . . . . . . . . . . . . . . . . 5
3.3.1. New State Variables . . . . . . . . . . . . . . . . . 5 3.3.1. New State Variables . . . . . . . . . . . . . . . . . 5
3.3.2. State Variable Initialization and Maintenance . . . . 6 3.3.2. State Variable Initialization and Maintenance . . . . 6
3.4. Controlling Multipoint BFD Options . . . . . . . . . . . 7 3.4. Controlling Multipoint BFD Options . . . . . . . . . . . 7
3.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 7 3.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 8
3.6. Session Establishment . . . . . . . . . . . . . . . . . . 7 3.6. Session Establishment . . . . . . . . . . . . . . . . . . 8
3.7. Discriminators and Packet Demultiplexing . . . . . . . . 8 3.7. Discriminators and Packet Demultiplexing . . . . . . . . 8
3.8. Controlling Tail Packet Transmission . . . . . . . . . . 8 3.8. Controlling Tail Packet Transmission . . . . . . . . . . 8
3.9. Soliciting the Tails . . . . . . . . . . . . . . . . . . 9 3.9. Soliciting the Tails . . . . . . . . . . . . . . . . . . 9
3.10. Verifying Connectivity to Specific Tails . . . . . . . . 9 3.10. Verifying Connectivity to Specific Tails . . . . . . . . 9
3.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 10 3.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 10
3.12. MultipointClient Down/AdminDown Sessions . . . . . . . . 10 3.12. MultipointClient Down/AdminDown Sessions . . . . . . . . 11
3.13. Base Specification Text Replacement . . . . . . . . . . . 11 3.13. Base BFD Specification Text Replacement . . . . . . . . . 11
3.13.1. Reception of BFD Control Packets . . . . . . . . . . 11 3.13.1. Reception of BFD Control Packets . . . . . . . . . . 11
3.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 11 3.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 12
3.13.3. Transmitting BFD Control Packets . . . . . . . . . . 12 3.13.3. Transmitting BFD Control Packets . . . . . . . . . . 12
4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Operational Scenarios . . . . . . . . . . . . . . . . . . . . 13 5. Operational Scenarios . . . . . . . . . . . . . . . . . . . . 13
5.1. No Head Notification . . . . . . . . . . . . . . . . . . 13 5.1. No Head Notification . . . . . . . . . . . . . . . . . . 14
5.2. Unreliable Head Notification . . . . . . . . . . . . . . 14 5.2. Unreliable Head Notification . . . . . . . . . . . . . . 14
5.3. Semi-reliable Head Notification and Tail Solicitation . . 14 5.3. Semi-reliable Head Notification and Tail Solicitation . . 14
5.4. Reliable Head Notification . . . . . . . . . . . . . . . 14 5.4. Reliable Head Notification . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
10. Normative References . . . . . . . . . . . . . . . . . . . . 16 10. Normative References . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This application of BFD is an extension to Multipoint BFD This application of BFD is an extension to Multipoint BFD
[I-D.ietf-bfd-multipoint] which allows tail to unreliably notify the [I-D.ietf-bfd-multipoint], which allows tail to unreliably notify the
head of the lack of multipoint connectivity. As a further option, head of the lack of multipoint connectivity. As a further option,
this notification can be made reliable. Notification to the head can this notification can be made reliable. Notification to the head can
be enabled for all tails, or for only a subset of the tails. be enabled for all tails, or for only a subset of the tails.
Multipoint BFD base document [I-D.ietf-bfd-multipoint] describes Multipoint BFD base document [I-D.ietf-bfd-multipoint] describes
procedures to verify only the head-to-tail connectivity over the procedures to verify only the head-to-tail connectivity over the
multipoint path. Although it may use unicast paths in both multipoint path. Although it may use unicast paths in both
directions, Multipoint BFD does not verify those paths (and in fact directions, Multipoint BFD does not verify those paths (and in fact
it is preferable if unicast paths share as little fate with the it is preferable if unicast paths share as little fate with the
multipoint path as is feasible.) multipoint path as is feasible.)
Goal of this application is for the head to reasonably rapidly have Goal of this application is for the head to reasonably rapidly have
knowledge of tails that have lost connectivity from the head. knowledge of tails that have lost connectivity from the head.
Since scaling is a primary concern (particularly state implosion Since scaling is a primary concern (particularly state implosion
toward the head), it is a required that the head be in control of all toward the head), it is required that the head be in control of all
timing aspects of the mechanism, and that BFD packets from the tails timing aspects of the mechanism, and that BFD packets from the tails
to the head not be synchronized. to the head not be synchronized.
Throughout this document, the term "multipoint" is defined as a
mechanism by which one or more systems receive packets sent by a
single sender. This specifically includes such things as IP
multicast and point-to-multipoint MPLS.
Term "connectivity" in this document is not being used in context of
connectivity verification in transport network but as an alternative
to "continuity", i.e. existence of a path between the sender and the
receiver.
This document effectively modifies and adds to the base BFD This document effectively modifies and adds to the base BFD
specification and base BFD multipoint document. specification [RFC5880] and base BFD multipoint document
[I-D.ietf-bfd-multipoint].
2. Overview 2. Overview
Head may wish to be alerted to the tails' connectivity (or lack Head may wish to be alerted to the tails' connectivity (or lack
thereof), there are a number of options. First, if all that is thereof), there are a number of options. First, if all that is
needed is an unreliable failure notification, the head can direct the needed is an unreliable failure notification, the head can direct the
tails to transmit unicast BFD Control packets back to the head when tails to transmit unicast BFD Control packets back to the head when
the path fails. the path fails.
If the head wishes to know the identity of the tails on the If the head wishes to know the identity of the tails on the
skipping to change at page 4, line 24 skipping to change at page 4, line 39
Individual tails may be configured so that they never send BFD Individual tails may be configured so that they never send BFD
control packets to the head, even when the head wishes notification control packets to the head, even when the head wishes notification
of path failure from the tail. Such tails will never be known to the of path failure from the tail. Such tails will never be known to the
head, but will still be able to detect multipoint path failures from head, but will still be able to detect multipoint path failures from
the head. the head.
3. Protocol Details 3. Protocol Details
This section describes the operation of BFD Multipoint active tail in This section describes the operation of BFD Multipoint active tail in
detail. This section is update to section 4 of detail. This section is update to section 4 of
[I-D.ietf-bfd-multipoint] [I-D.ietf-bfd-multipoint].
3.1. Multipoint Client Session 3.1. Multipoint Client Session
If the head is keeping track of some or all of the tails, it has a If the head is keeping track of some or all of the tails, it has a
session of type MultipointClient per tail that it cares about. All session of type MultipointClient per tail that it cares about. All
of the MultipointClient sessions for tails on a particular multipoint of the MultipointClient sessions for tails on a particular multipoint
path are grouped with the MultipointHead session to which the clients path are grouped with the MultipointHead session to which the clients
are listening. A BFD Poll Sequence may be sent over such a session are listening. A BFD Poll Sequence may be sent over such a session
to a tail if the head wishes to verify connectivity. These sessions to a tail if the head wishes to verify connectivity. These sessions
receive any BFD Control packets sent by the tails, and never transmit receive any BFD Control packets sent by the tails, and never transmit
skipping to change at page 5, line 18 skipping to change at page 5, line 28
modifies the usage of a few existing ones defined in section 4.4 of modifies the usage of a few existing ones defined in section 4.4 of
[I-D.ietf-bfd-multipoint]. [I-D.ietf-bfd-multipoint].
3.3.1. New State Variables 3.3.1. New State Variables
Few state variables are added and modified support of Multipoint BFD Few state variables are added and modified support of Multipoint BFD
active tail. active tail.
bfd.SessionType bfd.SessionType
The type of this session as defined in The type of this session as defined in [RFC7880]. A new value
[I-D.ietf-bfd-multipoint]. A new value introduced is: introduced is:
MultipointClient: A session on the head that tracks the MultipointClient: A session on the head that tracks the
state of an individual tail, when desirable. state of an individual tail, when desirable.
This variable MUST be initialized to the appropriate type when This variable MUST be initialized to the appropriate type when
the session is created, according to the rules in section 4.13 the session is created, according to the rules in section 4.13
of [I-D.ietf-bfd-multipoint]. of [I-D.ietf-bfd-multipoint].
bfd.SilentTail bfd.SilentTail
skipping to change at page 9, line 42 skipping to change at page 10, line 6
3.10. Verifying Connectivity to Specific Tails 3.10. Verifying Connectivity to Specific Tails
If the head wishes to verify connectivity to a specific tail, the If the head wishes to verify connectivity to a specific tail, the
corresponding MultipointClient session MAY send a BFD Poll Sequence corresponding MultipointClient session MAY send a BFD Poll Sequence
to said tail. This might be done in reaction to the expiration of to said tail. This might be done in reaction to the expiration of
the Detection Timer (the tail didn't respond to a multipoint Poll), the Detection Timer (the tail didn't respond to a multipoint Poll),
or it might be done on a proactive basis. or it might be done on a proactive basis.
The interval between transmitted packets in the Poll Sequence MUST be The interval between transmitted packets in the Poll Sequence MUST be
calculated as specified in the base specification (the greater of calculated as specified in the base BFD specification [RFC5880] (the
bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval.) greater of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval.)
The value transmitted in Required Min RX Interval will be used by the The value transmitted in Required Min RX Interval will be used by the
tail (rather than the value received in any multipoint packet) when tail (rather than the value received in any multipoint packet) when
it transmits BFD Control packets to the head notifying it of a it transmits BFD Control packets to the head notifying it of a
session failure, and the transmitted packets will not be delayed. session failure, and the transmitted packets will not be delayed.
This value can potentially be set much lower than in the multipoint This value can potentially be set much lower than in the multipoint
case, in order to speed up notification to the head, since the value case, in order to speed up notification to the head, since the value
will be used only by the single tail. This value (and the lack of will be used only by the single tail. This value (and the lack of
delay) are "sticky", in that once the tail receives it, it will delay) are "sticky", in that once the tail receives it, it will
continue to use it indefinitely. Therefore, if the head no longer continue to use it indefinitely. Therefore, if the head no longer
skipping to change at page 10, line 25 skipping to change at page 10, line 37
connectivity, though a reply to a Poll Sequence does reliably connectivity, though a reply to a Poll Sequence does reliably
indicate connectivity or lack thereof (by virtue of the tail's state indicate connectivity or lack thereof (by virtue of the tail's state
not being Up in the BFD Control packet.) not being Up in the BFD Control packet.)
3.11. Detection Times 3.11. Detection Times
MultipointClient sessions at the head are always in Demand mode, and MultipointClient sessions at the head are always in Demand mode, and
as such only care about detection time in two cases. First, if a as such only care about detection time in two cases. First, if a
Poll Sequence is being sent on a MultipointClient session, the Poll Sequence is being sent on a MultipointClient session, the
detection time on this session is calculated according to the base detection time on this session is calculated according to the base
specification, that is, the transmission interval multiplied by BFD specification [RFC5880], that is, the transmission interval
bfd.DetectMult. Second, when a multipoint Poll is sent to solicit multiplied by bfd.DetectMult. Second, when a multipoint Poll is sent
tail replies, the detection time on all associated MultipointClient to solicit tail replies, the detection time on all associated
sessions that aren't currently sending Poll Sequences is set to a MultipointClient sessions that aren't currently sending Poll
value greater than or equal to bfd.RequiredMinRxInterval (one packet Sequences is set to a value greater than or equal to
time.) This value can be made arbitrarily large in order to ensure bfd.RequiredMinRxInterval (one packet time.) This value can be made
that the detection time is greater than the BFD round trip time arbitrarily large in order to ensure that the detection time is
between the head and the tail with no ill effects, other than greater than the round trip time of a BFD Control packet between the
delaying the detection of unresponsive tails. Note that a detection head and the tail with no ill effects, other than delaying the
time expiration on a MultipointClient session at the head, while detection of unresponsive tails. Note that a detection time
expiration on a MultipointClient session at the head, while
indicating a BFD session failure, cannot be construed to mean that indicating a BFD session failure, cannot be construed to mean that
the tail is not hearing multipoint packets from the head. the tail is not hearing multipoint packets from the head.
3.12. MultipointClient Down/AdminDown Sessions 3.12. MultipointClient Down/AdminDown Sessions
If the MultipointHead session is going down (which only happens If the MultipointHead session is going down (which only happens
administratively), all associated MultipointClient sessions SHOULD be administratively), all associated MultipointClient sessions SHOULD be
destroyed as they are superfluous. destroyed as they are superfluous.
If a MultipointClient session goes down due to the receipt of an If a MultipointClient session goes down due to the receipt of an
skipping to change at page 11, line 13 skipping to change at page 11, line 26
the session SHOULD be maintained. the session SHOULD be maintained.
If the tail replies to a Poll Sequence with state Down or AdminDown, If the tail replies to a Poll Sequence with state Down or AdminDown,
it means that the tail session is definitely down. In this case, the it means that the tail session is definitely down. In this case, the
session MAY be destroyed. session MAY be destroyed.
If the Detection Time expires on a MultipointClient session (meaning If the Detection Time expires on a MultipointClient session (meaning
that the tail did not reply to a Poll Sequence) the session MAY be that the tail did not reply to a Poll Sequence) the session MAY be
destroyed. destroyed.
3.13. Base Specification Text Replacement 3.13. Base BFD Specification Text Replacement
The following sections are meant to replace the corresponding The following sections are meant to replace the corresponding
sections in the base specification. sections in the base specification.
3.13.1. Reception of BFD Control Packets 3.13.1. Reception of BFD Control Packets
The following procedure replaces section 6.8.6 of [RFC5880]. The following procedure replaces section 6.8.6 of [RFC5880].
When a BFD Control packet is received, procedure defined in section When a BFD Control packet is received, procedure defined in section
4.13.1 of [I-D.ietf-bfd-multipoint] MUST be followed, in the order 4.13.1 of [I-D.ietf-bfd-multipoint] MUST be followed, in the order
skipping to change at page 14, line 7 skipping to change at page 14, line 16
5.1. No Head Notification 5.1. No Head Notification
Since the only path used in this scenario is the multipoint path, Since the only path used in this scenario is the multipoint path,
none of the others matter. A failure in the multipoint path will none of the others matter. A failure in the multipoint path will
result in the tail noticing the failure within a detection time, and result in the tail noticing the failure within a detection time, and
the head will remain ignorant of the tail state. the head will remain ignorant of the tail state.
5.2. Unreliable Head Notification 5.2. Unreliable Head Notification
In this scenario, the tail sends back unsolicicted BFD packets in In this scenario, the tail sends back unsolicited BFD packets in
response to the detection of a multipoint path failure. It uses the response to the detection of a multipoint path failure. It uses the
reverse unicast path, but not the forward unicast path. reverse unicast path, but not the forward unicast path.
If the multipoint path fails but the reverse unicast path stays up, If the multipoint path fails but the reverse unicast path stays up,
the tail will detect the failure within a detection time, and the the tail will detect the failure within a detection time, and the
head will know about it within one reverse packet time (since the head will know about it within one reverse packet time (since the
notification is delayed.) notification is delayed.)
If both the multipoint path and the reverse unicast paths fail, the If both the multipoint path and the reverse unicast paths fail, the
tail will detect the failure but the head will remain unaware of it. tail will detect the failure but the head will remain unaware of it.
skipping to change at page 16, line 21 skipping to change at page 16, line 31
9. Acknowledgements 9. Acknowledgements
Authors would also like to thank Nobo Akiya, Vengada Prasad Govindan, Authors would also like to thank Nobo Akiya, Vengada Prasad Govindan,
Jeff Haas, Wim Henderickx, Gregory Mirsky and Mingui Zhang who have Jeff Haas, Wim Henderickx, Gregory Mirsky and Mingui Zhang who have
greatly contributed to this document. greatly contributed to this document.
10. Normative References 10. Normative References
[I-D.ietf-bfd-multipoint] [I-D.ietf-bfd-multipoint]
Katz, D., Ward, D., and J. Networks, "BFD for Multipoint Katz, D., Ward, D., and J. Networks, "BFD for Multipoint
Networks", draft-ietf-bfd-multipoint-10 (work in Networks", draft-ietf-bfd-multipoint-11 (work in
progress), April 2017. progress), December 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
Pallagatti, "Seamless Bidirectional Forwarding Detection
(S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
<https://www.rfc-editor.org/info/rfc7880>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Authors' Addresses Authors' Addresses
Dave Katz Dave Katz
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, California 94089-1206 Sunnyvale, California 94089-1206
USA USA
Email: dkatz@juniper.net Email: dkatz@juniper.net
skipping to change at page 17, line 4 skipping to change at page 17, line 22
Email: dkatz@juniper.net Email: dkatz@juniper.net
Dave Ward Dave Ward
Cisco Systems Cisco Systems
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, California 95134 San Jose, California 95134
USA USA
Email: wardd@cisco.com Email: wardd@cisco.com
Santosh Pallagatti (editor) Santosh Pallagatti (editor)
Individual Contributor Individual Contributor
Embassy Business Park Embassy Business Park
Bangalore, KA 560093 Bangalore, KA 560093
India India
Email: santosh.pallagatti@gmail.com Email: santosh.pallagatti@gmail.com
Greg Mirsky (editor)
ZTE Corp.
Email: gregimirsky@gmail.com
 End of changes. 27 change blocks. 
41 lines changed or deleted 66 lines changed or added

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