wdiff draft-hao-trill-address-flush-00.txt draft-hao-trill-address-flush-01.txt

TRILL Working Group Weiguo Hao
INTERNET-DRAFT Donald Eastlake
Intended status: Proposed Standard Yizhou Li
Huawei
Expires: April 17, 2015 October 18, September 20, 2015 March 21, 2016

TRILL: Address Flush Protocol
<draft-hao-trill-address-flush-00.txt> Message
<draft-hao-trill-address-flush-01.txt>

Abstract

The TRILL (TRansparent Interconnection of Lots of Links) protocol, by
default, learns end station addresses from observing the data plane.
This document specifies an optional a message by which an originating TRILL
switch can explicitly flush addresses learned by request other TRILL switches to flush certain
MAC reachability learned through the egress of data ingress by that originating TRILL
switch. Data packets.
This is a supplement to the TRILL automatic address forgetting and
can assist in achieving more rapid convergence. convergence in case of topoogy or
configuration change.

Status of This Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Distribution of this document is unlimited. Comments should be sent
to the TRILL working group mailing list. list: trill@ietf.org.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

INTERNET-DRAFT Address Flush Protocol Message

Table of Contents

1. Introduction............................................3
1.1 Terminology and Acronyms...............................3

2. Address Flush Message Details...........................5
2.1 VLAN Block Case........................................6
2.2 Extensible Case........................................7

3. IANA Considerations.....................................9 Considerations....................................11
4. Security Considerations.................................9 Considerations................................11

Normative References......................................10 References......................................12
Informative References....................................10
Acknowledgements..........................................10 References....................................12
Acknowledgements..........................................12

Authors' Addresses........................................11 Addresses........................................13

INTERNET-DRAFT Address Flush Protocol Message

1. Introduction

Edge TRILL (Transparent Interconnection of Lots of Links [RFC6325])
switches, Links) switches
[RFC6325] [RFC7780], also called edge RBridges, by default learn end
station MAC
addresses address reachability from observing the data plane. On
receipt of a native frame from an end station, they would learn the
local MAC address attachment of the source end station. And on
egressing (decapsulating) a remotely originated TRILL Data frame, packet,
they learn the remote MAC address and remote attachment TRILL switch.
Such learning is all appropriately scoped by data label (VLAN or Fine Grained Label
[RFC7172]).

TRILL has mechanisms for timing out such learning and appropriately
clearing it based on some network connectivity and configuration
changes; however, there are circumstances under which it would be
helpful for a TRILL switch to be able to explicitly flush (clear) (purge)
certain learned end station reachability information in remote
RBridges to achieve more rapid convergence (see, for example,
[TCaware] and Section 6.2 of [RFC4762]). Obivously a

A TRILL switch R1 can easily flush any locally learned addresses it
wants. This document specifies an optional RBridge Channel protocol [RFC7178]
message to request flushing such learned address information learned from
decapsulating at remote TRILL switches. This Address Flush
message makes use of the RBridge Channel facility [RFC7178], which
supports typed message transmission between RBridges.

1.1 Terminology and Acronyms

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

This document uses the terms and acronyms defined in [RFC6325] and
[RFCchannel]
[ChannelTunnel] as well as the following:

AFN

Data Label - Address Family Number ([RFC4760] where it is called Address
Family Identifier (AFI)). VLAN or FGL.

Edge TRILL switch - A TRILL switch attached to one or more links
that provide end station service.

FGL - Fine Grained Label [RFC7172].

Management VLAN - A VLAN in which all TRILL switches in a campus
indicate interest so that multi-destinaiton TRILL Data packets,
including RBridge Channel messages [RFCchannel], [ChannelTunnel], sent with
that VLAN as the Inner.VLAN will be delivered to all TRILL
switches in the campus. Usually no end station service is
offered in the Management VLAN.

INTERNET-DRAFT Address Flush Message

RBridge - A alterntive name for a TRILL switch.

TRILL switch - A device implementing the TRILL protocol.

INTERNET-DRAFT Address Flush Protocol

Edge TRILL switch - A TRILL switch attached to one or more links
that provide end station service.

INTERNET-DRAFT Address Flush Protocol Message

2. Address Flush Message Details

The Address Flush message makes use of the is an RBridge Channel protocol message
[RFC7178].

Although initial use is expected to be to flush 48-bit MAC addresses
[RFC7042], the protocol accommodates flushing other types of end
station addresses; there have been suggestion for TRILL switches to
learn IP addresses from the data plane [INFOCOM], TRILL might be
extended to accommodate 64-bit MAC addresses, or similar future
extensions might benefit from the ability to flush other types of
learned addresses.

The general structure of an RBridge Channel packet on a link between
TRILL switches is shown in Figure 1 below. The type of RBridge
Channel packet is given by a the Protocol field in the RBridge Channel
Header that indicates how to interpret the Channel Protocol Specific
Payload [RFC7178l].

+-----------------------------------+ [RFC7178].

+----------------------------------+
| Link Header |
+-----------------------------------+
+----------------------------------+
| TRILL Header |
+--------------------------------+ |
+----------------------------------+
| Inner Ethernet Addresses | |
+--------------------------------+ |
+----------------------------------+
| Data Label (VLAN or FGL) | |
+--------------------------------+--+
+----------------------------------+
| RBridge Channel Header |
+-----------------------------------+
+----------------------------------+
| Channel Protocol Specific Payload |
+-----------------------------------+ Payload|
+----------------------------------+
| Link Trailer (FCS if Ethernet) |
+-----------------------------------+ Ethernet)|
+----------------------------------+

Figure 1. RBridge Channel Packet Protocol Message Structure

An Address Flush RBridge Channel message normally by default applies to
addresses within the VLAN or FGL [RFC7178] Data Label in the TRILL Header. Address Flush
protocol messages are usually sent as multi-
destination multi-destination packets
(TRILL Header M bit equal to one) so as to reach all TRILL switches
offering end station service in the VLAN or FGL specified by the Data
Label. However, and address flush protocol
message can Such messages SHOULD be sent unicast, if it is desired to clear addresses at
one TRILL switch only. And there priority 6 since they are
important control messages but lower priority than control messages
that establish or maintain adjacency.

Nevertheless:
- There are provisions for optionally indicating the Data Label with the address(es) Label(s)
to be flushed for cases where the
address flush protocol Address Flush message is sent
over a Managagement VLAN or the like.
- An Address Flush message can be sent unicast, if it is desired to
clear addresses at one TRILL switch only.

INTERNET-DRAFT Address Flush Message

2.1 VLAN Block Case

Figure 2 below expands the RBridge Channel Header and Channel

INTERNET-DRAFT Address Flush Protocol
Protocol Specific Payload from Figure 1 for the case of the VLAN
based Address Flush message. This form of the Address Flush message
is optimized for flushing MAC addressed based on nickname and blocks
of VLANs.

Figure 2. Address Flush Channel Message Structure - VLAN Case

The fields in Figure 2 related to the Address Flush message are as
follows:

Channel Protocol: The RBridge Channel Protocol value allocated
for Address Flush (see Section 3).

SF: The 2-bit SF ("super flush") field values have the following
meanings:

0: No special effect.

1: All addresses learned at the receiving TRILL switch due to
egressing TRILL Data packets fror

K-nicks: K-nicks is the TRILL switch
originating number of nicknames present as an unsigned
integer. If this Address Flush message are flushed for is zero, the
data label ingress nickname in the TRILL Header. Any ADDRESS RECORDs in
Header is considerted to be the
rest of only nickname to which the
message for that data label can be ignored but
there may be ADDRESS RECORDs applies. If non-zero, it given the number of nicknames
present that apply to other
data labels.

2: All addresses learned at which the receiving TRILL switch message applies. The messages flushes
address learning due to egressing TRILL Data packets from that had a
ingress nicknam to which the message applies.

INTERNET-DRAFT Address Flush Message

Nickname: A listed nickname to which it is intended that the TRILL switch
originating this
Address Flush message are apply. If an unknown or reserved
nickname occurs in the list, it is ignored but the address
flush operation is still executed with the other nicknames. If
an incorrect nickname occurs in the list, so some address
learning is flushed across
all data labels. The remainder that should not have been flush, the
network will strill operate correctly but will be less
efficient as the incorrectly flushed learning is re-learned.

K-VBs: K-VBs is the number of VLAN blocks present as an unsigned
integer. If this byte is zero, the Address Flush message,
including message is the value more general
format specified in Section 2.2. If it is non-zero, it gives
the number of K, are ignored.

INTERNET-DRAFT Address Flush Protocol

3: Reserved. Ignored on receipt. blocks of VLANs present.

RESV: 4 reserved flag bits. Must MUST be sent as zero and ignored on
recipet.

K: The number
receipt.

Start.VLAN, End.VLAN: These 12-bit fields give the beginning and
ending VLAN IDs of ADDRESS RECORDs present. See below. a block of VLANs. The structure block includes both
the starting and endiing values so a block of size one is
indicated by setting End.VLAN equal to Start.VLAN. If
Start.VLAN is 0x000, it is treated as if it was 0x001. If
End.VLAN is 0xFFF, it is treated as if it was 0xFFE. If
End.VLAN is smaller than Start.VLAN, considering both as
unsigned integers, that VLAN block is ignored but the ADDRESSES RECORD address
flush operation is still executed with any other VLAN blocks in
the message.

This message flushes all addresses learned from egressing TRILL Data
packets with an applicable nickname and a VLAN in any of the blocks
given. To flush addresses for all VLANs, it is easy to specify a
block covering all valid VLAN IDs, this is, from 0x001 to 0xFFE.

2.2 Extensible Case

A more general form of the Address Flush message is provided to
support flushing by FGL and more efficient encodings of VLANs and
FGLs where using a set of contiguous blocks if cumbersome. This form
is also extensible to handle future requirements.

It is indicated by a zero in the byte shown in Figure 2 as follows: "K-VBs".

INTERNET-DRAFT Address Flush Message

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
RBridge Channel Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|N|R| Size
| Count RBridge-Channel (0x8946) | 0x0 | AFN Channel Protocol = TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Label (Optional)
+-+-+-+-+-+-+-+-+-+-+-+-+-... Flags | ERR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Flush Protocol Specific:
+-+-+-+-+-+-+-+-+
| K-nicks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname 1 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Address Nickname 2 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address K Nickname ... | Nickname K-nicks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Dependent Information
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

Figure 3. Structure of ADDRESSES RECORD

L: Label present. Address Flush Message - Extensible Case

Channel Protocol, K-nicks, Nickname: These fields are as specified
in Section 2.1.

Type: If this bit the byte immediately before the Type field, which is a one, the optional Data Label
shown
byte labeled "K-VBs" in present. If it Figure 2, is zero, there is no data label and the addresses listed are withing the data labe given Type byte
indicates the type of extended Address Flush message as
follows:

Type Description
------ ------------
0 Reserved
1 Bit Map of VLANs
2 Blocks of FGLs
3 List of FGLs
4 Bit Map of FGLs
5-254 Unassigned
255 Reserved

Length: The length of the remaining information in the
TRILL Header.

N: No Specific Addresses. If Address
Flush message.

Type Dependent Information: Depends on the value of the type field
as further specified below in this bit section.

INTERNET-DRAFT Address Flush Message

Type 1
Bit Map of VLANs: The Type Dependent Information consists of two
bytes with the 12-bit starting VLAN ID N right justified (the top
4 bits are as specified above for RESV). This is followed by bytes
with one and Count bit per VLAN ID. The high order bit of the first byte is
zero
for VLAN N, the next to 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 is a second byte, is for VLAN
N+8, and L so on. If that bit is a one, then flush all addresses learned at the
receiving TRILL switch due to egressing TRILL Data packets
from the TRILL switch originating this Address Flush
message
are flushed for the Data Label given in the ADDRESS RECORD. applies to that VLAN. If this that bit is zero or Count is non-zero or L is a zero, they
this special flush action is then
addresses that have been learned in that VLAN are not performed.

R: A reserved bit flushed.
Note that Length MUST be sent as zero and at least 3. If Length is ignored on
receipt.

Size: The size of each Address in bytes. The presence of this
field makes it possible 0, 1, or 2 for a receiving TRILL switch to skip
an ADDRESS RECORD even if it does not understand the value
in the AFN field. Size MUST NOT be zero; a zero size field
indicates a corrupt Addresses
Type 1 extended Address Flush message and message, the entire message is ignored. corrupt and
MUST be discarded. VLAN IDs do not wrap around. If there are
enough bytes so that some bits correspond to VLAN ID 0xFFF or
nigher, those bits are ignored but the correct size message is still processed
for an Address

INTERNET-DRAFT bits corresponding to valid VLAN IDs.

Type 2
Blocks of FGLs: The Type Dependent Information consists of sets of
Start.FGL and End.FGL numbers. The Address Flush Protocol

of information
applies to the type FGLs in that range, incluse. A single FGL is
indicated by have both Start.FGL and End.FGL to the AFN field, for example 6 for
48-bit MAC addresses. same value. If these conditions are violated,
End.FGL is less than Start.FGL, considering them as unsigned
integers, that block is ignored but the Address Flush message is
still processed for any other blocks present. For this Type,
Length MUST be a multiple of 6; if it is not, the message is
considered corrup and MUST be discarded.

Count: The number

Type 3
List of occurrences FGLs: The Type Dependent Information consists of an FGL numbers
each in 3 bytes. The Address Flush message applies to flush in those FGLs.
For this
ADDRESS RECORD. May be zero. All Addresses Type, Length MUST fit within
the RBridge Channel Message. If they do be a multiple of 3; if it is not, the
message is considered corrup and MUST be discarded.

AFN:

Type 4
Bit Map of FGLs: The Address Family Number Type Dependent Information consists of three
bytes with the 24-bit starting FGL N. This is followed by bytes
with one bit per FGL. The high order bit of the first byte is for
FGL N, the type next to the highest order bit is for FGL N+1, the low
order bit of addresses
present as assigned by IANA. (The AFN the first byte is for 48-bit MAC
addresses FGL N+7, the high order bit of
the second byte, if there is 0x4005.)

Data Label: An optional Data Label (VLAN or FGL) in a second byte, is for FGL N+8, and so
on. If that bit is a one, the same
format as Data Labels the Address Flush message applies to
that appear FGL. If that bit is a zero, then addresses that have been
learned in that FGL are not flushed. Note that Length MUST be at
least 4. If Length is 0, 1, 2, or 3 for a Type 1 extended Address
Flush message, the TRILL Header.
Included in message is corrupt and MUST be discarded. FGLs
do not wrap around. If there are enough bytes so that some bits
correspond to an ADDRESS RECORD only if FGL higher than 0xFFFFFF, those bits are ignored
but the L bit message is still processed for bits corresponding to valid

INTERNET-DRAFT Address Flush Message

FGLs.

There is no provision for a one.

Address: An instance list of VLAN IDs as there are few enough
of them that an address to arbitrary subset of VLAN IDs can always be flushed.
represented as a bit map.

INTERNET-DRAFT Address Flush Protocol Message

3. IANA Considerations

IANA has allocated tbd1 for is requested to assign TBD as the Address Flush RBridge Channel
Protocol number from the range of RBridge Channel protocols allocated
by Standards Action [RFC7178].

The added RBridge Channel protocols registry entry on the TRILL
Parameters web page is as follows:

Protocol Description Reference
-------- -------------- ------------------
TBD Address Flush [this document]

4. Security Considerations

The Address Flush RBridge Channel Protocol provides no security
assurances or features. However, use of the Address Flush protocol
can be nested inside the RBridge Channel Tunnel Protocol [RFCtunnel]
[ChannelTunnel] using the RBridge Channel message payload type. The
Channel Tunnel protocol can provide some security services.

See [RFC7178] for general RBridge Channel Security Considerations.

See [RFC6325] for general TRILL Security Considerations.

INTERNET-DRAFT Address Flush Protocol Message

Normative References

[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4760] - Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.

[RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A.
Ghanwani, "RBridges: Base Protocol Specification", RFC 6325,
July 2011.

[RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R.,
and D. Dutt, "Transparent Interconnection of Lots of Links
(TRILL): Fine-Grained Labeling", RFC 7172, DOI
10.17487/RFC7172, May 2014, <http://www.rfc-
editor.org/info/rfc7172>.

[RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
Ward, "Transparent Interconnection of Lots of Links (TRILL):
RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May
2014, <http://www.rfc-editor.org/info/rfc7178>.

Informative References

[INFOCOM]

[RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., "RBridges: Transparent Routing", Proc.
Infocom 2005, March 2004. Banerjee, A.,
Ghanwani, A., and S. Gupta, "Transparent Interconnection of
Lots of Links (TRILL): Clarifications, Corrections, and
Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
<http://www.rfc-editor.org/info/rfc7780>.

Informative References

[RFC4762] - Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, January 2007.

[RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and
IETF Protocol and Documentation Usage for IEEE 802 Parameters",
BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013,
<http://www.rfc-editor.org/info/rfc7042>.

[RFCtunnel]

[ChannelTunnel] - Eastlake, D., ... M. Umair, Y. Li, "TRILL: RBridge
Channel Tunnel", draft-
eastlake-trill-channel-tunnel, Tunnel Protocol", draft-ietf-trill-channel-tunnel, work
in progress.

[TCaware] - Y. Li, et al., "Aware Spanning Tree Topology Change on
RBridges" draft-yizhou-trill-tc-awareness, work-in-progress.

Acknowledgements

The document was prepared in raw nroff. All macros used were defined
within the source file.

INTERNET-DRAFT Address Flush Protocol Message

Authors' Addresses

Weiguo Hao
Huawei Technologies
101 Software Avenue,
Nanjing 210012, China

Phone: +86-25-56623144
Email: haoweiguo@huawei.com

Donald E. Eastlake, 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757 USA

Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com

Yizhou Li
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China

Phone: +86-25-56624629
Email: liyizhou@huawei.com

INTERNET-DRAFT Address Flush Protocol Message

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. The definitive version of
an IETF Document is that published by, or under the auspices of, the
IETF. Versions of IETF Documents that are published by third parties,
including those that are translated into other languages, should not
be considered to be definitive versions of IETF Documents. The
definitive version of these Legal Provisions is that published by, or
under the auspices of, the IETF. Versions of these Legal Provisions
that are published by third parties, including those that are
translated into other languages, should not be considered to be
definitive versions of these Legal Provisions. For the avoidance of
doubt, each Contributor to the IETF Standards Process licenses each
Contribution that he or she makes as part of the IETF Standards
Process to the IETF Trust pursuant to the provisions of RFC 5378. No
language to the contrary, or terms, conditions or rights that differ
from or are inconsistent with the rights and licenses granted under
RFC 5378, shall have any effect and shall be null and void, whether
published or posted by such Contributor, or included with or in such
Contribution.