< draft-ietf-trill-address-flush-02.txt   draft-ietf-trill-address-flush-03.txt >
TRILL Working Group Weiguo Hao TRILL Working Group Weiguo Hao
INTERNET-DRAFT Donald Eastlake INTERNET-DRAFT Donald Eastlake
Intended status: Proposed Standard Yizhou Li Intended status: Proposed Standard Yizhou Li
Huawei Huawei
Mohammed Umair Mohammed Umair
IPinfusion Cisco
Expires: July 26, 2017 January 26, 2017 Expires: January 19, 2018 July 20, 2017
TRILL: Address Flush Message TRILL: Address Flush Message
<draft-ietf-trill-address-flush-02.txt> <draft-ietf-trill-address-flush-03.txt>
Abstract Abstract
The TRILL (TRansparent Interconnection of Lots of Links) protocol, by The TRILL (TRansparent Interconnection of Lots of Links) protocol, by
default, learns end station addresses from observing the data plane. default, learns end station addresses from observing the data plane.
In particular, it learns local MAC addresses and edge switch port of In particular, it learns local MAC addresses and edge switch port of
attachment from the receipt of local data frames and learns remote attachment from the receipt of local data frames and learns remote
MAC addresses and edge switch of attachment from the decapsulation of MAC addresses and edge switch of attachment from the decapsulation of
remotely sourced TRILL Data packets. remotely sourced TRILL Data packets.
This document specifies a message by which an originating TRILL This document specifies a message by which a TRILL switch can
switch can explicitly request other TRILL switches to flush certain explicitly request other TRILL switches to flush certain MAC
MAC reachability learned through the decapsulation of TRILL Data reachability learned through the decapsulation of TRILL Data packets.
packets. This is a supplement to the TRILL automatic address This is a supplement to the TRILL automatic address forgetting and
forgetting and can assist in achieving more rapid convergence in case can assist in achieving more rapid convergence in case of topology or
of topology or configuration change. configuration change.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent Distribution of this document is unlimited. Comments should be sent
to the TRILL working group mailing list: trill@ietf.org. to the TRILL working group mailing list: trill@ietf.org.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 4, line 31 skipping to change at page 4, line 31
changes; however, there are circumstances under which it would be changes; however, there are circumstances under which it would be
helpful for a TRILL switch to be able to explicitly flush (purge) helpful for a TRILL switch to be able to explicitly flush (purge)
certain learned end station reachability information in remote certain learned end station reachability information in remote
RBridges to achieve more rapid convergence. For example, in the case RBridges to achieve more rapid convergence. For example, in the case
of topology change or reconfiguration in a bridged network attached of topology change or reconfiguration in a bridged network attached
to multiple edge RBridges. Section 6.2 of [RFC4762] is another to multiple edge RBridges. Section 6.2 of [RFC4762] is another
example of use of such a mechanism. example of use of such a mechanism.
A TRILL switch R1 can easily flush any locally learned addresses it A TRILL switch R1 can easily flush any locally learned addresses it
wants. This document specifies an RBridge Channel protocol [RFC7178] wants. This document specifies an RBridge Channel protocol [RFC7178]
message to request flushing address information learned from message to request flushing address information learned at remote
decapsulating at remote RBridges. RBridges from decapsulating TRILL Data packets.
1.1 Terminology and Acronyms 1.1 Terminology and Acronyms
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses the terms and acronyms defined in [RFC6325] and This document uses the terms and acronyms defined in [RFC6325] and
[RFC7978] as well as the following: [RFC7978] as well as the following:
skipping to change at page 5, line 11 skipping to change at page 5, line 11
including RBridge Channel messages [RFC7978], sent with that including RBridge Channel messages [RFC7978], sent with that
VLAN as the Inner.VLAN will be delivered to all TRILL switches VLAN as the Inner.VLAN will be delivered to all TRILL switches
in the campus. Usually no end station service is offered in the in the campus. Usually no end station service is offered in the
INTERNET-DRAFT Address Flush Message INTERNET-DRAFT Address Flush Message
Management VLAN. Management VLAN.
RBridge - An alternative name for a TRILL switch. RBridge - An alternative name for a TRILL switch.
TRILL switch - A device implementing the TRILL protocol. TRILL switch - A device implementing the TRILL protocol [RFC6325]
[RFC7780].
INTERNET-DRAFT Address Flush Message INTERNET-DRAFT Address Flush Message
2. Address Flush Message Details 2. Address Flush Message Details
The Address Flush message is an RBridge Channel protocol message The Address Flush message is an RBridge Channel protocol message
[RFC7178]. [RFC7178].
The general structure of an RBridge Channel packet on a link between The general structure of an RBridge Channel packet on a link between
TRILL switches is shown in Figure 1 below. The Protocol field in the TRILL switches is shown in Figure 1 below. The Protocol field in the
RBridge Channel Header gives the type of RBridge Channel packet that RBridge Channel Header gives the type of RBridge Channel packet and
indicates how to interpret the Channel Protocol Specific Payload indicates how to interpret the Channel Protocol Specific Payload
[RFC7178]. [RFC7178].
+----------------------------------+ +----------------------------------+
| Link Header | | Link Header |
+----------------------------------+ +----------------------------------+
| TRILL Header | | TRILL Header |
+----------------------------------+ +----------------------------------+
| Inner Ethernet Addresses | | Inner Ethernet Addresses |
+----------------------------------+ +----------------------------------+
skipping to change at page 8, line 7 skipping to change at page 8, line 7
K-nicks: K-nicks is the number of nicknames listed as an unsigned K-nicks: K-nicks is the number of nicknames listed as an unsigned
integer. If this is zero, the ingress nickname in the TRILL integer. If this is zero, the ingress nickname in the TRILL
Header [RFC6325] is considered to be the only nickname to which Header [RFC6325] is considered to be the only nickname to which
the message applies. If non-zero, it given the number of the message applies. If non-zero, it given the number of
nicknames listed right after K-nicks to which the message nicknames listed right after K-nicks to which the message
applies and, in this non-zero case, the flush does not apply to applies and, in this non-zero case, the flush does not apply to
the ingress nickname in the TRILL Header unless it is also the ingress nickname in the TRILL Header unless it is also
INTERNET-DRAFT Address Flush Message INTERNET-DRAFT Address Flush Message
listed. The messages flushes address learning due to egressing listed. The message flushes address learning due to egressing
TRILL Data packets that had an ingress nickname to which the TRILL Data packets that had an ingress nickname to which the
message applies. message applies.
Nickname: A listed nickname to which it is intended that the Nickname: A listed nickname to which it is intended that the
Address Flush message apply. If an unknown or reserved Address Flush message apply. If an unknown or reserved
nickname occurs in the list, it is ignored but the address nickname occurs in the list, it is ignored but the address
flush operation is still executed with the other nicknames. If flush operation is still executed with the other nicknames. If
an incorrect nickname occurs in the list, so some address an incorrect nickname occurs in the list, so some address
learning is flushed that should not have been flush, the learning is flushed that should not have been flush, the
network will still operate correctly but will be less efficient network will still operate correctly but will be less efficient
skipping to change at page 9, line 37 skipping to change at page 9, line 37
Channel Protocol, K-nicks, Nickname: These fields are as specified Channel Protocol, K-nicks, Nickname: These fields are as specified
in Section 2.1. in Section 2.1.
TLVs: If the byte immediately before the TLVs field, which is the TLVs: If the byte immediately before the TLVs field, which is the
byte labeled "K-VLBs" in Figure 2, is zero, as shown in Figure byte labeled "K-VLBs" in Figure 2, is zero, as shown in Figure
3, the remainder of the message consists of TLVs encoded as 3, the remainder of the message consists of TLVs encoded as
shown in Figure 4. shown in Figure 4.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Value | Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 4. Type, Length, Value Figure 4. Type, Length, Value
Type: The 8 bit TLV type as shown in the table below. See Type: The 8-bit TLV type as shown in the table below. See
subsections of this Section 2.2 for details on each type subsections of this Section 2.2 for details on each type
assigned below. If the type is reserved or not known by a assigned below. If the type is reserved or not known by a
receiving RBridge, that receiving RBridge ignores the value and receiving RBridge, that receiving RBridge ignores the value and
can easily skip to the next TLV by use of the Length byte. skips to the next TLV by use of the Length byte. There is no
There is no provision for a list of VLAN IDs TLV as there are provision for a list of VLAN IDs TLV as there are few enough of
few enough of them that an arbitrary subset of VLAN IDs can be them that an arbitrary subset of VLAN IDs can be represented as
represented as a bit map. a bit map.
INTERNET-DRAFT Address Flush Message INTERNET-DRAFT Address Flush Message
Type Description Reference Type Description Reference
------ ------------------ ----------------- ------ ------------------ -----------------
0 Reserved [this document] 0 Reserved [this document]
1 Blocks of VLANs [this document] 1 Blocks of VLANs [this document]
2 Bit Map of VLANs [this document] 2 Bit Map of VLANs [this document]
3 Blocks of FGLs [this document] 3 Blocks of FGLs [this document]
4 List of FGLs [this document] 4 List of FGLs [this document]
skipping to change at page 10, line 33 skipping to change at page 10, line 33
Length: The 8-bit unsigned integer length of the remaining Length: The 8-bit unsigned integer length of the remaining
information in the TLV after the length byte. The length MUST information in the TLV after the length byte. The length MUST
NOT imply that the value extends beyond the end of RBridge NOT imply that the value extends beyond the end of RBridge
Channel Protocol Specific Payload area. If it does, the Address Channel Protocol Specific Payload area. If it does, the Address
Flush message is corrupt and MUST be ignored. Flush message is corrupt and MUST be ignored.
Value: Depends on the TLV type. Value: Depends on the TLV type.
The TLVs in an extensible Address Flush message are parsed with types The TLVs in an extensible Address Flush message are parsed with types
unknown by the receiving RBridge ignored. unknown by the receiving RBridge ignored.
All RBridges implementing the Address Flush RBridge Channel
message MUST implement types 1 and 2, the VLAN types, and type 6,
which indicates addresses are to be flushed for all Data Labels.
RBridges that implement FGL ingress/egress MUST implement types 3,
4, and 5, the FGL types. (An RBridge that is merely FGL safe
[RFC7172], but cannot egress FGL TRILL Data packets, SHOULD ignore
the FGL types as it will not learn any FGL scoped MAC addresses from
the data plane.)
RBridges SHOULD implement types 7 and 8 so that specific MAC
addresses can be flushed. If they do not, the effect will be to flush
all MAC addresses for the indicated Data Labels, which will be
inefficient as those not intended to be flushed will have to be re-
learned.
The processing requirements based on support for Address Flush The parsing of the TLVs by a receiving RBridge results in three items
Channel message plus the additional types: of information: a flag indicating whether one or more type 6 TLVs
(All Data Labels) were encountered; a set of Data Labels and blocks
Basic RBridges functionality: All RBridges supporting the Address of data labels compiled from VLAN and/or FGL specifying TLVs in the
Flush Channel message MUST implement type 1 (Blocks of VLANs), message; and, if the MAC address TLV types are implemented, a set of
type 2 (Bit map of VLANs), and type 6 (All Data labels). Type 6 MAC addresses and blocks of MAC addresses compiled from MAC address
indicates that all addresses are to be flushed for all data labels. specifying TLVs in the message. If the set of MAC addresses and
blocks of MAC address is null, the address flush message applies to
Optional RBridges functionality: RBridges SHOULD implement types 7 all MAC addresses. If the flag indicating the presence of an All Data
and type 8 so that specific MAC addresses can be can be flushed. Labels TLV is true, then the address flush message applies to all
If a set of RBridges does not implement types 7 and 8, the flush
will be inefficient as those not intent to be flashed will have to
be relearned.
FGL functionality : All RBridges implementing the FGL ingress/egress
support and the Address Flush Channel message MUST implement
type 3 (Blocks of FGLs), type 4 (Lists of FGLs),
and type 5 (Bit Map of FGL). An RBridge that is merely FGL
safe [RFC7172], but cannot egress TRILL data packets, SHOULD ignore
the FGL types with the Address Flush Channel message as it will not
learn any MAC addresses with FGL scope from the MAC data plane.
The parsing of the TLVs in an Rbridge Channel Message in the Address
Flush Protocol Specific TLVS by a receiving bridge results in three
items:
INTERNET-DRAFT Address Flush Message INTERNET-DRAFT Address Flush Message
1) A flag indicating whether one or more types Data Labels and the set of Data Labels and block of Data labels
6 TLVs (All Data Labels) were encountered. specified has no effect. If the flag indicating the presence of an
2) A set of Data labels and blocks of data labels compiled from All Data Labels TLV is false, then the address flush messages applies
VLAN TLVs (types 1 and 2), and/or FGL TLVs (types 3, 4, and 5). only to the set of Data Labels and blocks of Data Labels; if that set
3) If a MAC TLVs types (type 6 and 7) are implemented, a set of is null, the address flush message does nothing.
MAC addresses and Blocks of MAC addresses from the MAC TLVs.
For the following flag settings, the processing is as follows:
a) If the set of MAC addresses and Block of MAC address is null
(item 3 above) then Address Flush applies to all messages.
b) If the All-Data-label-found flag (item 1 above) is true,
then the address flush message applies to all data labels.
The set of Data label and block of data labels (item 2 above)
does not have any effect.
c) If the All-Data-label-found flag (item 1 above) is false, then
the Address Flush message applies to the set of
Data labels (see item 2 above) found in VLAn
TLVs (types 1 and 2), and/or FGLs TLVS (types 3, 4, and 5).
If the set of Data Labels (see item 2 above) is null, the
Address Flush message does nothing.
2.2.1 Blocks of VLANs 2.2.1 Blocks of VLANs
If the TLV Type is 1, the value is a list of blocks of VLANs as If the TLV Type is 1, the value is a list of blocks of VLANs as
follows: follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length | | Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN 1 | RESV | End.VLAN 1 | | RESV | Start.VLAN 1 | RESV | End.VLAN 1 |
skipping to change at page 12, line 4 skipping to change at page 11, line 43
If the TLV Type is 2, the value is a bit map of VLANs as follows: If the TLV Type is 2, the value is a bit map of VLANs as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length | | Type = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| RESV | Start.VLAN | Bits... | RESV | Start.VLAN | Bits...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
The value portion of the TLV begins with two bytes having the 12-bit The value portion of the TLV begins with two bytes having the 12-bit
INTERNET-DRAFT Address Flush Message
starting VLAN ID right justified (the top 4 bits are as specified in starting VLAN ID right justified (the top 4 bits are as specified in
Section 2.1 RESV). This is followed by bytes with one bit per VLAN Section 2.1 RESV). This is followed by bytes with one bit per VLAN
ID. The high order bit of the first byte is for VLAN N, the next to ID. The high order bit of the first byte is for VLAN N, the next to
the highest order bit is for VLAN N+1, the low order bit of the first the highest order bit is for VLAN N+1, the low order bit of the first
byte is for VLAN N+7, the high order bit of the second byte, if there byte is for VLAN N+7, the high order bit of the second byte, if there
is a second byte, is for VLAN N+8, and so on. If that bit is a one, is a second byte, is for VLAN N+8, and so on. If that bit is a one,
the Address Flush message applies to that VLAN. If that bit is a the Address Flush message applies to that VLAN. If that bit is a
zero, then addresses that have been learned in that VLAN are not zero, then addresses that have been learned in that VLAN are not
flushed. Note that Length MUST be at least 2. If Length is 0 or 1 flushed. Note that Length MUST be at least 2. If Length is 0 or 1
the TLV is corrupt and the Address Flush message MUST be ignored. the TLV is corrupt and the Address Flush message MUST be ignored.
INTERNET-DRAFT Address Flush Message
VLAN IDs do not wrap around. If there are enough bytes so that some VLAN IDs do not wrap around. If there are enough bytes so that some
bits correspond to VLAN ID 0xFFF or higher, those bits are ignored bits correspond to VLAN ID 0xFFF or higher, those bits are ignored
but the message is still processed for bits corresponding to valid but the message is still processed for bits corresponding to valid
VLAN IDs. VLAN IDs.
2.2.3 Blocks of FGLs 2.2.3 Blocks of FGLs
If the TLV Type is 3, the value is a list of blocks of FGLs as If the TLV Type is 3, the value is a list of blocks of FGLs as
follows: follows:
skipping to change at page 14, line 11 skipping to change at page 14, line 11
2.2.6 All Data Labels 2.2.6 All Data Labels
If the TLV Type is 6, the value is null as follows: If the TLV Type is 6, the value is null as follows:
INTERNET-DRAFT Address Flush Message INTERNET-DRAFT Address Flush Message
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Length = 0 | | Type = 6 | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This type is used when a RBridge want to withdraw all Address for all This type is used when a RBridge want to withdraw all addresses for
the Data Labels (all VLANs and FGLs), Length MUST be zero. If Length all the Data Labels (all VLANs and FGLs). Length MUST be zero. If
is any other value, the TLV is corrupt and the Address Flush message Length is any other value, the TLV is corrupt and the Address Flush
MUST be ignored. message MUST be ignored.
2.2.7 MAC Address List 2.2.7 MAC Address List
If the TLV Type is 7, the value is a list of MAC addresses as If the TLV Type is 7, the value is a list of MAC addresses as
follows: follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 | Length | | Type = 7 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC 1 upper half | | MAC 1 upper half |
skipping to change at page 16, line 27 skipping to change at page 16, line 27
The added RBridge Channel protocols registry entry on the TRILL The added RBridge Channel protocols registry entry on the TRILL
Parameters web page is as follows: Parameters web page is as follows:
Protocol Description Reference Protocol Description Reference
-------- -------------- ------------------ -------- -------------- ------------------
TBD Address Flush [this document] TBD Address Flush [this document]
3.2 TRILL Address Flush TLV Types 3.2 TRILL Address Flush TLV Types
IANA is requested to create a TRILL Address Flush TLV Types registry IANA is requested to create a TRILL Address Flush TLV Types registry
on the TRILL Parameters web page indented right after the RBridge on the TRILL Parameters web page indented after the RBridge Channel
Channel Protocols registry. Registry headers are as below. The Protocols registry. Registry headers are as below. The initial
initial entries are as in the table in Section 2.2 above. entries are as in the table in Section 2.2 above.
Registry: TRILL Address Flush TLV Types Registry: TRILL Address Flush TLV Types
Registration Procedures: IETF Review Registration Procedures: IETF Review
Reference: [this document] Reference: [this document]
INTERNET-DRAFT Address Flush Message INTERNET-DRAFT Address Flush Message
4. Security Considerations 4. Security Considerations
The Address Flush RBridge Channel Protocol provides no security The Address Flush RBridge Channel Protocol provides no security
assurances or features. However, the Address Flush protocol messages assurances or features. However, the Address Flush protocol messages
can be secured by use of the RBridge Channel Header Extension can be secured by use of the RBridge Channel Header Extension
[RFC7978]. [RFC7978]. Forged Address Flush messages can reduce network
efficiency, by purging useful learned information that will have to
be re-learned, but cannot cause incorrect operation.
See [RFC7178] for general RBridge Channel Security Considerations. See [RFC7178] for general RBridge Channel Security Considerations.
See [RFC6325] for general TRILL Security Considerations. See [RFC6325] for general TRILL Security Considerations.
INTERNET-DRAFT Address Flush Message INTERNET-DRAFT Address Flush Message
Normative References Normative References
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 19, line 35 skipping to change at page 19, line 35
Yizhou Li Yizhou Li
Huawei Technologies Huawei Technologies
101 Software Avenue, 101 Software Avenue,
Nanjing 210012 Nanjing 210012
China China
Phone: +86-25-56624629 Phone: +86-25-56624629
Email: liyizhou@huawei.com Email: liyizhou@huawei.com
Mohammed Umair Mohammed Umair
IPinfusion Cisco
RMZ Centennial Mahadevapura Post Cessna Business Park, Kadubeesanahalli Village, Hobli,
Bangalore, 560048 India Sarjapur, Varthur Main Road, Marathahalli,
Bengaluru, Karnataka 560087 India
Email: mohammed.umair2@gmail.com Email: mohammed.umair2@gmail.com
INTERNET-DRAFT Address Flush Message INTERNET-DRAFT Address Flush Message
Copyright, Disclaimer, and Additional IPR Provisions Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2016 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
(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
 End of changes. 20 change blocks. 
82 lines changed or deleted 68 lines changed or added

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