wdiff rfc8139.original rfc8139.txt

TRILL Working Group Donald
Internet Engineering Task Force (IETF) D. Eastlake
INTERNET-DRAFT Yizhou 3rd
Request for Comments: 8139 Y. Li
Intended status: Proposed Standard Huawei
Obsoletes: 6439 Mohammed Umair Huawei
Updates: 6325, 7177 IPinfusion
Ayan M. Umair
Category: Standards Track IP Infusion
ISSN: 2070-1721 A. Banerjee
Cisco
Fangwei
F. Hu
ZTE
Expires: August 20,
June 2017 February 21, 2017

TRILL:

Transparent Interconnection of Lots of Links (TRILL):
Appointed Forwarders
<draft-ietf-trill-rfc6439bis-05.txt>

Abstract

TRILL (Transparent Interconnection of Lots of Links) supports multi-
access LAN (Local Area Network) links where a single link can have
multiple end stations and TRILL switches attached. Where multiple
TRILL switches are attached to a link, native traffic to and from end
stations on that link is handled by a subset of those TRILL switches
called "Appointed Forwarders" as originally specified in RFC 6325,
with the intent that native traffic in each VLAN be handled by at
most one TRILL switch. This document clarifies and updates the
Appointed Forwarder mechanism. It updates RFC 6325, updates RFC 7177, RFCs 6325 and 7177 and
obsoletes RFC 6439.

Status of This Document Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. Distribution of this an Internet Standards Track document.

This document is
unlimited. Comments should be sent to the TRILL working group mailing
list <trill@ietf.org>.

Internet-Drafts are working documents a product of the Internet Engineering Task Force (IETF), its areas,
(IETF). It represents the consensus of the IETF community. It has
received public review and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of six months RFC 7841.

Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It
http://www.rfc-editor.org/info/rfc8139.

This document is inappropriate subject to use Internet-Drafts 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 reference
material or they describe your rights and restrictions with respect
to cite them other than this document. Code Components extracted from this document must
include Simplified BSD License text as "work described in progress."

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

INTERNET-DRAFT TRILL: Appointed Forwarders
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction...........................................4
1.1 Introduction ....................................................4
1.1. Appointed Forwarders and Active-Active.................5
1.2 Active-Active .....................5
1.2. Terminology and Acronyms...............................5 Abbreviations ..............................6
2. Appointed Forwarders and Their Appointment..............7
2.1 Appointment ......................7
2.1. The Appointment Databases and DRB Actions..............8
2.2 Actions ..................8
2.2. Appointment Effects of DRB Elections...................9
2.2.1 Elections ......................10
2.2.1. Processing Forwarder Appointments in Hellos.........10
2.2.2 Hellos ........11
2.2.2. Frequency of Hello Appointments.....................12
2.2.3 Appointments ....................13
2.2.3. Appointed Forwarders Hello Limit....................12
2.3 Limit ...................13
2.3. Effects of Local Configuration Actions Appointment Effects.......13
2.4 on Appointments ....14
2.4. Overload and Appointed Forwarders.....................13
2.5 Forwarders .........................14
2.5. VLAN Mapping within a Link............................14 Link ................................15
3. The Inhibition Mechanism...............................15
3.1 Mechanism .......................................15
3.1. Inhibited Appointed Forwarder Behavior................17
3.2 Behavior ....................18
3.2. Root Bridge Change Inhibition Optimizations..................17
3.2.1 Optimizations ...............18
3.2.1. Optimization for Change to Lower Priority...........18
3.2.2 Priority ..........19
3.2.2. Optimization for Change to Priority Only............18
3.2.3 Settling Only ...........19
3.2.3. Optimizing the Detection Optimization.....................18 of Completed Settling .....19
4. Optional TRILL Hello Reduction.........................20 Reduction .................................20
5. Multiple Ports on the Same Link........................22 Link ................................22
6. Port-Shutdown Messages.................................23
6.1 Messages .........................................23
6.1. Planned Shutdown and Hellos...........................23
6.2 Hellos ...............................23
6.2. Port-Shutdown Message Structure.......................23
6.3 Structure ...........................23
6.3. Port-Shutdown Message Transmission....................24
6.4 Transmission ........................24
6.4. Port-Shutdown Message Reception.......................25
6.5 Reception ...........................25
6.5. Port-Shutdown Message Security........................25
6.6 Security ............................25
6.6. Port-Shutdown Configuration...........................25 Configuration ...............................26
7. FGL-VLAN Mapping Consistency Checking..................27 Checking ..........................26
8. Support of E-L1CS......................................28
8.1 Backwards Compatibility...............................28 E-L1CS ..............................................27
8.1. Backward Compatibility ....................................27
9. Security Considerations................................29 Considerations ........................................28
10. Code Points and Data Structures.......................30
10.1 Structures ...............................28
10.1. IANA Considerations..................................30
10.2 Appointment Bitmap APPsub-TLV........................30
10.3 Appointment List APPsub-TLV..........................31
10.4 FGL-VLAN Mapping Bitmap APPsub-TLV...................32
10.5 FGL-VLAN Mapping Pairs APPsub-TLV....................34 Considerations ......................................28
10.2. AppointmentBitmap APPsub-TLV .............................29
10.3. AppointmentList APPsub-TLV ...............................30
10.4. FGL-VLAN-Bitmap APPsub-TLV ...............................31
10.5. FGL-VLAN-Pairs APPsub-TLV ................................32
11. Management Considerations.............................35

INTERNET-DRAFT TRILL: Appointed Forwarders

Table of Contents (continued) Considerations .....................................33
12. References ....................................................34
12.1. Normative References......................................36 References .....................................34
12.2. Informative References....................................37

Acknowledgements..........................................38
Authors' Addresses........................................39 References ...................................36
Appendix A: A. VLAN Inhibition Example.......................40
Appendix B: Changes to RFCs 6325, 6439, 7177..............41 Example ...............................37
Appendix C: B. Multi-Link VLAN Mapping Loop Example..........42 Example ..................38
Appendix Z: Change Record.................................44

INTERNET-DRAFT TRILL: Appointed Forwarders 7177 ..................39
Acknowledgments ...................................................40
Authors' Addresses ................................................41

1. Introduction

The IETF TRILL (Transparent Interconnection of Lots of Links)
protocol [RFC6325] [RFC7780] provides optimal pair-wise pairwise data frame
forwarding without configuration in multi-hop networks with arbitrary
topology and link technology, safe forwarding even during periods of
temporary loops, and support for multipathing of both unicast and
multicast traffic. TRILL accomplishes this these by using IS-IS
(Intermediate System to Intermediate System) [IS-IS] [RFC7176] link
state
link-state routing and encapsulating traffic using a header that
includes a hop count. The design supports VLANs, FGLs (Fine Grained Labels
[RFC7172]), (Fine-Grained
Labels) [RFC7172], and optimization of the distribution of
multi-destination frames based on VLANs and multicast groups.
Devices that implement TRILL are called TRILL switches or "RBridges"
(Routing Bridges).

Section 2 of [RFC7177] discusses the environment for which the TRILL
protocol is designed and the differences between that environment and
the typical Layer 3 routing environment.

TRILL supports multi-access LAN (Local Area Network) links that can
have multiple end stations and TRILL switches attached. Where
multiple TRILL switches are attached to a link, native traffic to and
from end stations on that link is handled by a subset of those
switches called "Appointed Forwarders" as originally specified in
[RFC6325], with the intent that native traffic in each VLAN be
handled by at most one switch. A TRILL switch can be Appointed
Forwarder for many VLANs.

The purpose of this document is to update and improve the Appointed
Forwarder mechanism and free it from the limitations imposed by the
requirement in its initial design that all appointments fit within a
TRILL Hello PDU. Protocol Data Unit (PDU). This is accomplished by
requiring support of link
scoped link-scoped FS-LSPs (Flooding Scoped - Scope Link State PDUs, Section 7)
PDUs) (Section 8) and
proving for providing the option to send appointment
information to optionally be sent in those LSPs. In addition addition, this document provides a
number of other optional features to (1)

1. detect inconsistent VLAN to FGL VLAN-ID-to-FGL [RFC7172] mappings among the
TRILL switch ports on a link link, as discussed in Section 7, (2)

2. expedite notification of ports going down so that Appointed
Forwarders can be adjusted adjusted, as discussed in Section 6, and (3)

3. reduce or eliminate the need for "inhibition" of ports for loop safety
safety, as discussed in Section 3.2.

This document replaces and obsoletes [RFC6439], incorporating the
former material in [RFC6439] with these additions. The various
optimizations are orthogonal and optional. Implementers can choose
to provide all, some, or none of them them, and TRILL switches will still
be interoperable. In accordance with the TRILL design philosophy,
these optimizations require zero or minimal
configuration configuration, but there
are a couple of configurable parameters parameters, as summarized in Section 11.

This document, as

As described in Appendix B, C, this document updates [RFC6325] by

INTERNET-DRAFT TRILL: Appointed Forwarders
mandating support of E-L1CS FS-LSPs and provides backwards backward
compatibility in the presence of legacy TRILL switches that do not
provide this support. It also updates [RFC7177] by providing, as an
optional optimization, that receipt of the port shutdown Port-Shutdown message
specified herein be treated as an event in the state machine
specified in [RFC7177].

This document includes reference implementation details. Alternative
implementations that interoperate on the wire are permitted.

The Appointed Forwarder mechanism is irrelevant to any link on which
end station
end-station service is not offered. This includes links configured
as point-to-point IS-IS links and any link with all TRILL switch
ports on that link configured as trunk ports. (In TRILL,
configuration of a port as a "trunk port" just means that no end
station
end-station service will be provided. It does not imply that all
VLANs are enabled on that port.)

The Appointed Forwarder mechanism has no effect on the formation of
adjacencies, the election of the Designated RBridge (DRB, [RFC7177]) (DRB) [RFC7177]
for a link, MTU matching, or pseudonode formation. Those topics are
covered in [RFC7177]. Furthermore, Appointed Forwarder status has
no effect on the forwarding of TRILL Data frames; it only affects the
handling of native frames to and from end stations.

For other aspects of the TRILL base protocol, see [RFC6325],
[RFC7177], and [RFC7780]. In case cases of conflict between this document
and [RFC6325] or [RFC7177], this document prevails.

1.1

1.1. Appointed Forwarders and Active-Active

As discussed in [RFC7379], TRILL active-active provides support for
end stations connected to multiple edge TRILL switches where these
connections are separate links. Since TRILL Hellos are not forwarded
between these links, the Appointed Forwarder mechanism as described
herein operates separately on each such link.

1.2

1.2. Terminology and Acronyms Abbreviations

This document uses the acronyms abbreviations and terms defined in [RFC6325],
some of which are repeated below for convenience, and additional acronyms
abbreviations and terms listed below.

Data Label mapping: The mapping from VLAN ID to FGL and from FGL to
VLAN ID.

DRB: Designated RBridge. The RBridge on a link elected as specified
in [RFC7177] to handle certain decisions and tasks for that
link link,
including forwarder appointment as specified herein.

INTERNET-DRAFT TRILL: Appointed Forwarders

E-L1CS: Extended Level 1 Circuit Scoped Scope (Section 8).

FGL: Fine Grained Fine-Grained Label [RFC7172].

FS-LSP: Flooding Scoped - Scope Link State PDU (Section 8).

Link: The means by which adjacent TRILL switches are connected. A
TRILL link may be various technologies and, in the common case of
Ethernet, can be a "bridged LAN", LAN" -- that is to say, some
combination of Ethernet links with zero or more bridges, hubs,
repeaters, or the like.

LSDB: Link State Database.

PDU: Protocol Data Base. Unit.

RBridge: An alternative name for a TRILL switch.

TRILL: Transparent Interconnection of Lots of Links or Tunneled
Routing in the Link Layer.

TRILL switch: A device implementing the TRILL protocol. An
alternative name for an RBridge.

Trunk port: A TRILL switch port configured with the "end station "end-station
service disable" bit on, as described in Section 4.9.1 of
[RFC6325].

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

INTERNET-DRAFT TRILL: Appointed Forwarders
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

2. Appointed Forwarders and Their Appointment

The Appointed Forwarder on a link for VLAN-x is the TRILL switch
(RBridge) that ingresses native frames from the link and egresses
native frames to the link in VLAN-x. By default, the DRB (Designated
RBridge) on a link is in charge of native traffic for all VLANs on
the link. The DRB may, if it wishes, act as Appointed Forwarder for
any VLAN VLAN, and it may appoint other TRILL switches that have ports on
the link as Appointed Forwarder for one or more VLANs.

By definition, the DRB considers the other ports on the link to be
the ports with which a DRB port has adjacency on that link [RFC7177].
If the DRB loses adjacency to a TRILL switch that it has appointed a
as forwarder and the native traffic that was being handled by that
Appointed Forwarder is still to be ingressed and egressed, it SHOULD
immediately appoint another forwarder or itself become the forwarder
for that traffic.

It is important that there not be two Appointed Forwarders on a link
that are ingressing and egressing native frames for the same VLAN at
the same time. Should this occur, it could form a loop where frames
are not protected by a TRILL Hop Count for part of the loop. (Such a
condition can even occur through two Appointed Forwarders for two
different VLANs, VLAN-x and VLAN-y, if ports or bridges inside the
link are configured to map frames between VLAN-x and VLAN-y as
discussed in Section 2.5.) While TRILL tries to avoid such
situations, for loop safety there is also an "inhibition" mechanism
(see Section 3) that can cause a TRILL switch that is an Appointed
Forwarder to not to ingress or egress native frames. Appointed
Forwarder status and port "inhibition" have no effect on the
reception, transmission, or forwarding of TRILL Data or TRILL IS-IS
frames. Appointed Forwarder status and inhibition only affect the
handling of native frames.

As discussed in Section 5, an RBridge may have multiple ports on a
link. As discussed in [RFC7177], if there are multiple ports with
the same Media Access Control (MAC) address on the same link, all but
one will be suspended. The case of multiple ports on a link for the
same TRILL switch and the case of multiple ports with the same MAC
address on a link and link, as well as combinations of these cases cases, are fully
accommodated; however, the case of multiple ports on a link for the
same TRILL switch is expected to be a rare condition condition, and the case of
duplicate MAC addresses is not recommended by either TRILL or
IEEE 802.1 standards.

There are six mechanisms by which an RBridge can be appointed or un-
appointed
unappointed as Appointed Forwarder: (1)

1. assumption of appointment, when the DRB decides to act as
Appointed Forwarder for a VLAN, (2) Hello

2. E-L1CS appointment, as a result of appointments sent by the DRB in TRILL
Hellos, (3)
E-L1CS FS-LSPs,

3. Hello appointment, as a result of appointments sent by the DRB in E-L1CS FS-LSPs, (4)
TRILL Hellos,

4. as a result of the DRB elections

INTERNET-DRAFT TRILL: Appointed Forwarders [RFC7177] as discussed in
Section 2.2, (5)

5. as a result of a Port-
Shutdown Port-Shutdown message as discussed in Section 6,
and (6)

6. as a result of a local configuration action as discussed in
Section 2.3.

Mechanisms 2 and 3 are covered in Section 2.1.

2.1

2.1. The Appointment Databases and DRB Actions

The DRB MAY appoint other RBridges on the link as Appointed
Forwarders through the mechanisms A two mechanisms, "A" and B "B", as described below.

Each RBridge maintains two databases of appointment information:
(1) its E-L1CS LSDB that LSDB, which shows appointments that each RBridge on
the link would make using mechanism A if it that RBridge were the DRB,
and (2) its Hello appointment database that database, which shows the appointments
most recently sent by the DRB in a TRILL Hello. The E-L1CS LSDB is
semi-permanent and is only changed by E-L1CS FS-LSPs or IS-IS purges.
The Hello appointment database is more transient and is completely
reset by each Hello received from the DRB that contains any appointments and is
appointments; this database is also cleared under other circumstances
circumstances, as described below. An RBridge considers itself to be
the Appointed Forwarder for VLAN-x if this is indicated by either its
Hello appointment database or its E-L1CS LSDB entries from the DRB.

The two mechanisms by which the DRB can appoint other RBridges on a
link as Appointed Forwarders are as follows:

(A) The inclusion of one or more Appointed Forwarders sub-TLVs
[RFC7176], Appointment Bitmap AppointmentBitmap APPsub-TLVs (Section 10.2), or
Appointment List
AppointmentList APPsub-TLVs (Section 10.3) in E-L1CS LSPs it
sends on a link. Appointments sent with using this method will not be
seen by legacy RBridges that do not support E-L1CS (Section 8).

(B) The inclusion of one or more Appointed Forwarders sub-TLVs
[RFC7176] in a TRILL Hello it sends on the Designated VLAN out of
the port that won the DRB election. When the DRB sends any
appointments in a TRILL Hello, it must send all appointments it
is sending in Hellos for that link in that Hello. Any previous
appointment it has sent in a Hello that is not included is
implicitly revoked.

To avoid the size limitations of the Hello PDU, it is RECOMMENDED
that the E-L1CS FS-LSP method be used to distribute forwarder
appointments and that all RBridges on a link advertise by use this method to
advertise the appointments they would make if they were the DRB.
However, if some RBridges on a link do not support E-L1CS FS-LSPs,
then Hello appointments must be used for the DRB to appoint such
legacy RBridges
an Appointed Forwarder.

INTERNET-DRAFT TRILL: as Appointed Forwarders Forwarders.

Although the DRB does not need to announce the VLANs for which it has
chosen to act as Appointed Forwarder by sending appoints appointments for
itself, if the DRB wishes to revoke all appointments made in Hellos
for RBridges other than itself on the link, it can do so by sending a
TRILL Hello with just an appointment for itself for some VLAN.

How the DRB decides what other RBridges on the link, if any, to
appoint as forwarder for which some VLAN or VLANs is beyond the scope of
this document.

Unnecessary changes in Appointed Forwarders SHOULD NOT be made made, as
they may result in transient lack of end station end-station service.

Should the network manager have misconfigured the enabled VLANs and
Appointed Forwarders, resulting in two RBridges believing they are
Appointed Forwarders for the same VLAN, then the scenario described in
item 4 in Section 3 will cause one or more of the RBridges to be
inhibited for that VLAN VLAN, thus avoiding persistent loops.

When forwarder appointments are being encoded for transmission,
different patterns of VLANs are most efficiently encoded in different
ways. The following table gives advice for regarding the most efficient
encoding:
encoding for a given pattern:

sub-TLV and Reference
Pattern of VLAN IDs |enclosing TLV(s) and Reference
-----------------
------------------- ------------------------------------

Blocks of consecutive VLANs
Appointed Forwarders sub-TLV [RFC7176]
|Router Capabilities CAPABILITY TLV [RFC7981]
|or MT Capabilities MT-Capability TLV [RFC6329]

Scattered VLANs within a small range
Appointment Bitmap
AppointmentBitmap APPsub-TLV (Section 10.2)
|TRILL GENINFO TLV [RFC7357]

Scattered VLANs over a large range
Appointment List
AppointmentList APPsub-TLV (Section 10.3)
|TRILL GENINFO TLV [RFC7357]

2.2

2.2. Appointment Effects of DRB Elections

When a TRILL switch port on a link wins the DRB election, there are
four possible cases:

1. A TRILL switch believes that it was the DRB and remains the DRB: There
there is no change in Appointed Forwarder status. This also
applies in

INTERNET-DRAFT TRILL: Appointed Forwarders the corner case where a TRILL switch has more than one
port on a link, one of which was previously the DRB election
winner but has just lost the DRB election to a different port of
the same TRILL switch on the same link (possibly due to management
configuration of port priorities). In this case case, there also is no
change in which TRILL switch is the DRB.

2. A TRILL switch believes that it was not the DRB but has now won
the DRB election and become the DRB on a link: by default, it can
act as Appointed Forwarder for any VLANs on that link that it
chooses
chooses, as long as its port is not configured as a trunk port and
has that VLAN enabled (or at least one of its ports meets these
criteria, if it has more than one port on the link). It ignores
any previous forwarder appointment information it received from
other TRILL switches on the link.

3. A TRILL switch was not the DRB and does not become DRB the DRB, but it
observes that the port winning the DRB election has changed: The the
TRILL switch loses all Hello appointments. In addition, there are
two subcases:
3.a

a. The new winning port and the old winner are ports of different
TRILL switches on the link. In this case, it switches to using
the E-L1CS FS-LSP appointments for the winning TRILL switch.
3.b

b. The new winning port and the old winner are ports of the same
TRILL switch, which has two (or more) ports on the link:
Although
although the Hello appointments are still discarded, since the
same TRILL switch is the DRB, the E-L1CS FS-LSP appointments
are unchanged.

4. The winning port is unchanged: As as in case 1, there is no change in
Appointed Forwarder status.

2.2.1

2.2.1. Processing Forwarder Appointments in Hellos

When a non-DRB RBridge that can offer end station end-station service on a link
receives a TRILL Hello that is not discarded for one of the reasons
given in [RFC7177], it checks the source MAC address and the Port ID
and System ID in the Hello to determine if it is from the winning DRB
port. If it is not from that port, any forwarder appointment sub-
TLVs
sub-TLVs in the Hello are ignored, and there is no change in the
receiving RBridge's Appointed Forwarder status due to that Hello.
Also, if no forwarder appointment sub-TLVs are present in the TRILL
Hello, there is no change in the receiver's Appointed Forwarder
status due to that Hello.

However, if the TRILL Hello is from the winning DRB port and the
Hello includes one or more forwarder appointment sub-TLVs, then the
receiving RBridge sets its Hello appointment database to be the set
of VLANs

INTERNET-DRAFT TRILL: Appointed Forwarders that are have both of the following characteristics:

o The VLAN is listed as an appointment for it the receiving RBridge in
the Hello Hello, and are

o The VLAN is enabled on the
receiving port. port where the Hello was received.

(If the appointment includes VLAN IDs 0x000 or 0xFFF, they are
ignored, but any other VLAN IDs are still effective.) It then
becomes Appointed Forwarder for all the VLANs for which it is
appointed in either its Hello appointment database or its E-L1CS
FS-LSP appointment database from the DRB if the VLAN is enabled and
if the port is not configured as a trunk or IS-IS point-to-point
port. If the receiver was Appointed Forwarder for any VLANs because
they were in the Hello appointment database and they are no longer in
the Hello appointment database, its Appointed Forwarder status for
such VLANs is revoked. For example, if none of these sub-TLVs in a
Hello appoints the receiving RBridge, then it loses all Appointed
Forwarder status on the port where the Hello was received due to
Hello appointment database entries entries, but it retains Appointed
Forwarder status due to E-L1CS FS-LSP appointments.

The handling of one or more forwarder appointment sub-TLVs in a Hello
from the winning port that appoints the receiving RBridge is as
follows: An an appointment in an Appointed Forwarder Forwarders sub-TLV is for a
specific RBridge and a contiguous interval of VLAN IDs; however, as
stated above, it actually appoints that RBridge as forwarder only for
the VLAN(s) VLAN or VLANs in that range that are enabled on one or more ports
that RBridge has on the link (ignoring any ports configured as
trunk ports or as IS-IS point-to-point ports).

There is no reason for an RBridge to remember that it received a
valid appointment Hello message for a VLAN that was ineffective
because the VLAN was not enabled on the port where the Hello was
received or because the port was a trunk or point-to-point port. It
does not become Appointed Forwarder for such a VLAN just because that
VLAN is later enabled or the port is later reconfigured.

The limitations due to the size of the Hello PDU make it desirable to
use E-L1CS FS-LSPs for appointment. But if Hellos need to be used,
due to TRILL switches on the link not supporting E-L1CS FS-LSPs, the
remainder of this section gives provides a method to maximize the use of
the limited space in Hellos for forwarder appointment.

It should be straightforward for the DRB to send, within one Hello,
the appointments for several dozen VLAN IDs or several dozen blocks
of contiguous VLAN IDs. Should the VLANs that the DRB wishes to
appoint be inconveniently distributed (for example example, the proverbial
case where the a DRB RB1 (say RB1) wishes to appoint RB2 as forwarder for all even-
numbered
even-numbered VLANs and appoint RB3 as forwarder for all odd-numbered VLANs)
VLANs), the following method may be used:

The network manager normally controls what VLANs are enabled on an
RBridge port. Thus, the network manager can appoint an RBridge as
forwarder for an arbitrary set of scattered VLANs by enabling only
those VLANs on the relevant port (or ports) and then having the
DRB send an appointment that appears to appoint the target RBridge

INTERNET-DRAFT TRILL: Appointed Forwarders
as forwarder for all VLANs. However, for proper operation and inter-
RBridge
inter-RBridge communication, the Designated VLAN for a link SHOULD
be enabled on all RBridge ports on that link, and it may not be
desired to appoint the RBridge as forwarder for the
Designated VLAN. Thus, in the general case, it would require two appointments,
although it appointments
would still be required, although only require one appointment would be required
if the Designated VLAN value were an extreme extremely low or high value such (such as
VLAN
0xFFE 0xFFE) or the default VLAN 1. value (VLAN 1).

For example, assume that the DRB wants RB2 to be Appointed Forwarder
for all even-numbered VLANs and the Designated VLAN for the link is
VLAN 101. The network manager could cause all even-numbered VLANs
plus VLAN 101 to be enabled on the relevant port of RB2 and then,
with the desired effect, cause the DRB to send appointments to RB2
appointing it forwarder for all VLANs from 1 through 100 and from 102
through 4,094.

2.2.2

2.2.2. Frequency of Hello Appointments

Appointments made though through E-L1CS FS-LSPs use the same IS-IS timing
constants as those for LSP flooding. The general IS-IS link state link-state
flooding mechanism is robust and includes acknowledgements acknowledgments so that it
automatically recovers from lost PDUs, re-booted rebooted TRILL switches, and
the like.

For Hello appointments, it is not necessary for the DRB to include
the Hello forwarder appointments in every TRILL Hello that it sends
on the Designated VLAN for a link. For loop safety, every RBridge is
required to indicate, in every TRILL Hello it sends in VLAN-x on a
link, whether it is an Appointed Forwarder for VLAN-x for that link
(see item 4 in Section 3 3, but see also Section 4). It is also
RECOMMENDED that the DRB have enabled all VLANs for which end station end-station
service will be offered on the link as well as the Designated VLAN.
Thus, the DRB will generally be informed by other RBridges on the
link of the VLANs for which they believe that they are the Appointed
Forwarder. If this matches the appointments the DRB wishes to make,
it is not required to re-send resend its forwarder appointments; however, for
robustness, especially in cases such as VLAN misconfigurations in a
bridged LAN link, it is RECOMMENDED that the DRB send its forwarder
appointments on the Designated VLAN at least once per its Holding
Time on the port that won the DRB election.

2.2.3

2.2.3. Appointed Forwarders Hello Limit

The Hello mechanism of DRB forwarder appointment and the limited
length of TRILL Hellos impose a limit on the number of RBridges on a

INTERNET-DRAFT TRILL: Appointed Forwarders
link that can be Appointed Forwarders when E-L1CS FS-LSP appointments
cannot be used due to the presence of legacy RBridges. To obtain a
conservative estimate of this limit, assume that no more than 1000
1,000 bytes are available in a TRILL Hello for such appointments.
Assume also that it is desired to appoint various RBridges on a link
as forwarder for arbitrary non-intersecting sets of VLANs. Using the
technique discussed at the end of Section 2.2.1 would generally
require two appointments, or 12 bytes, per RBridge. With allowance
for sub-TLV and TLV overhead, appointments for 83 RBridges would
fit in under
1000 1,000 bytes. Including the DRB, this implies a link
with 84 or more RBridges attached. Links with more than a handful of
RBridges attached are expected to be rare. And rare, and in any case such
limitations are easily avoided by using E-L1CS FS-LSP appointment.

2.3

2.3. Effects of Local Configuration Actions Appointment Effects on Appointments

Disabling VLAN-x at an RBridge port cancels any Appointed Forwarder
status that RBridge has for VLAN-x VLAN-x, unless VLAN-x is enabled on some
other port that the RBridge has connected to the same link.
Configuring a port as a trunk port or point-to-point port revokes
any Appointed Forwarder status that depends on enabled VLANs at
that port.

Causing a port to no longer be configured as a trunk or point-to-
point
point-to-point port or enabling VLAN-x on a port does not necessarily
cause the RBridge to become an Appointed Forwarder for the link that
port is on. However, such actions allow the port's RBridge to become
Appointed Forwarder by choice if it is the DRB or, if it is not the
DRB on the link, by appointment as indicated by the Hello appointment
database or the E-L1CS FS-LSP appointment databases.

2.4 database.

2.4. Overload and Appointed Forwarders

A TRILL switch in link state link-state overload [RFC7780] will, in general, do
a poorer job of forwarding frames than a TRILL switch not in overload
overload, because the TRILL switch not in overload has full knowledge
of the campus topology. For example, as explained in [RFC7780], an
overloaded TRILL switch may not be able to distribute multi-
destination
multi-destination TRILL Data packets at all.

Therefore, the DRB SHOULD NOT appoint an RBridge in overload as an
Appointed Forwarder and, Forwarder, and if an Appointed Forwarder becomes
overloaded, the DRB SHOULD re-assign reassign VLANs from the overloaded RBridge
to another RBridge on the link that is not overloaded, if one is
available.

INTERNET-DRAFT TRILL: Appointed Forwarders

This does not violate the IS-IS standards prohibition on routing
through an overloaded node. Designation as an appointed forwarder has
to do with the ingress and egress of native frames and has nothing to
do with the IS-IS routing of TRILL Data packets through a TRILL
switch.

A counter-example where it would be best to appoint an RBridge in
overload as appointed forwarder Appointed Forwarder would be if RB1 was in overload but
all end stations in the campus in VLAN-x were on links attached to
RB1. In such a case, RB1 would never have to route VLAN-x end
station
end-station traffic as a TRILL Data packet packets but would always be
forwarding
it them locally as a native frame. frames. In this case, RB1
SHOULD NOT be disadvantaged for selection as the VLAN-x Appointed
Forwarder on any such links links, even if EB1 RB1 is in overload.

There is also the case where it is unavoidable to appoint an RBridge
in overload as appointed forwarder Appointed Forwarder, because all RBridges on the link
are in overload.

These cases do not violate the prohibition in the IS-IS standard
against routing through an overloaded node. Designation as an
Appointed Forwarder has to do with the ingress and egress of native
frames and has nothing to do with the IS-IS routing of TRILL Data
packets through a TRILL switch.

Overload does not affect DRB election election, but a TRILL switch in overload
MAY reduce its own priority to be the DRB.

2.5

2.5. VLAN Mapping within a Link

TRILL Hellos include a field that is set to the VLAN in which they
are sent when they are sent on a link technology such as Ethernet
that has outer VLAN labeling. (For link technologies such as PPP
that do not have outer VLAN labeling, this Hello field is ignored.)
If a TRILL Hello arrives on a different VLAN than the VLAN on which
it was sent on, sent, then VLAN mapping is occurring within the link. VLAN
mapping between VLAN-x and VLAN-y can lead to a loop if the Appointed
Forwarders for the VLANs are different. If such mapping within a
link was allowed and occurred on two or more links so that there was
a cycle of VLAN mappings, a multi-destination frame would loop
forever. Such a frame would be immortal. "immortal". For a specific example,
see Appendix C. B.

To prevent this potential problem, if the DRB on a link detects VLAN
mapping by receiving a Hello in VLAN-x that was sent on VLAN-y, it
MUST make or revoke appointments so as to assure that the same TRILL
switch (possibly the DRB) is the Appointed Forwarder on the link for
both VLAN-x and VLAN-y.

INTERNET-DRAFT TRILL: Appointed Forwarders

3. The Inhibition Mechanism

A TRILL switch has, for every link on which it can offer end station end-station
service (that is is, every link for which it can act as an Appointed
Forwarder), the following timers timers, denominated in seconds:

- a DRB inhibition timer,

- a root bridge change inhibition timer, and

- up to 4,094 VLAN inhibition timers, one for each legal VLAN ID.

The DRB and root bridge change inhibition timers MUST be implemented.

The loss of native traffic due to inhibition will be minimized by
logically implementing a VLAN inhibition timer per each VLAN for
which end station end-station service will ever be offered by the RBridge on the
link; this SHOULD be done. (See Appendix A for an example motivating
illustrating a potential problem that is solved by VLAN inhibition
timers.) However, if implementation limitations make a full set of
such timers impractical, the VLAN inhibition timers for more than one
VLAN can, with care, be merged into one timer. In particular, an
RBridge MUST NOT merge the VLAN inhibition timers
together for two VLANs if it
is the Appointer Appointed Forwarder for one and but not for the other, as this can
lead to unnecessary indefinitely prolonged inhibition. In the limit, a given
implementation limitation, there will be safe operations, albeit with
more native frame loss of native frames than would otherwise be required, even if
only two VLAN inhibition timers are provided: one for the VLANs for
which the RBridge is the Appointed Forwarder and one for all other
VLANs. Thus, at least two VLAN inhibition timers MUST be
implemented. Where a VLAN inhibition timer represents more than one
VLAN, an update or test that would have been done to the timer for
any of the VLANs is performed on the merged timer.

These timers are set as follows:

1. On booting or management reset, each port will have its own set of
timers, even if two or more such ports are on the same link,
because the TRILL switch will not have had a chance yet to learn
that they are on the same link. All inhibition timers are set to
expired
"expired", except the DRB inhibition timer that is set in
accordance with item 2 below. The DRB inhibition timer is handled
differently
differently, because each port will initially believe that it is
the DRB.

2. When a TRILL switch decides that it has become the DRB on a link,
including when it is first booted or reset by management, it sets
the DRB inhibition timer to the Holding Time of its port on that
link that won the DRB election.

3. When a TRILL switch decides that it has lost DRB status on a link,

INTERNET-DRAFT TRILL: Appointed Forwarders
it sets the DRB inhibition timer to expired. "expired".

Note: In the corner case where one port of a TRILL switch was the DRB
election winner, winner but later lost the DRB election to a different port
of the same TRILL switch on that link (perhaps due to management
configuration of port priorities), neither item 2 nor item 3 above
applies, and the DRB timer is not changed.

4. When a TRILL switch RB1 receives a TRILL Hello asserting that the
sender is the Appointed Forwarder and that Hello either
(1) arrives on VLAN-x or (2) was sent on VLAN-x as indicated
inside the Hello, then RB1 sets uses as its VLAN-x inhibition timer for the
link
to the maximum of (1) that timer's existing value and or (2) the Holding Time in
the received Hello. Hello, whichever is longer. A TRILL switch MUST
maintain VLAN inhibition timers covering a link to which it
connects if it can offer end station end-station service on that link link, even if
it is not currently the Appointed Forwarder for any VLAN on that
link.

5. When a TRILL switch RB1 enables VLAN-x on a port connecting to a
link and VLAN-x was previously not enabled on any of RB1's ports
on that link, it sets its VLAN inhibition timer for VLAN-x for
that link to its Holding Time for that port. This is done even if
the port is configured as a trunk or point-to-point port port, as long
as there is some chance it might later be configured not to be a
trunk or point-to-point port. Remember, inhibition has no effect
on TRILL Data or IS-IS packets, packets; inhibition only affects native
frames.

6. When a TRILL switch detects a change in the common spanning tree
root bridge on a port, it sets its root bridge change inhibition
timer for the link to an amount of time that defaults to
30 seconds and is configurable to any value from 30 down to zero
0 seconds. This condition will not occur unless the TRILL switch
is receiving Bridge PDU PDUs (BPDUs) on the port from an attached
bridged LAN; if no BPDUs are being received, the root bridge
change inhibition timer will never be set. It is safe to
configure this inhibition time to the settling time of an attached
bridged LAN. For example, if it is known that the Rapid Spanning
Tree Protocol (RSTP [802.1Q]) (RSTP) [802.1Q] is running throughout the attached
bridged LAN, it is safe to configure this inhibition time to
7 seconds or, if the attached bridges have been configured to have
a minimum Bridge Hello Timer, it is safe to configure it to
4 seconds. Further optimizations are specified in Section 3.2.

7. When a TRILL switch decides that one of its ports (or a set of its
ports) P1 is on the same link as another one of its ports (or set
of its ports) P2, then the inhibition timers are merged to into a single
set of inhibition timers by using the maximum longest value of the
corresponding timers as the initial value of the merged timers.

INTERNET-DRAFT TRILL: Appointed Forwarders

8. When an RBridge decides that a set of its ports that it had been
treating as being on the same link are no longer on the same link,
those ports will necessarily be on two or more links (one (up to one
link per
port in the limit). port). This is handled by cloning a copy of the timers
for each of the two or more links to which the TRILL switch has
decided these ports connect.

3.1

3.1. Inhibited Appointed Forwarder Behavior

Inhibition has no effect on the receipt or forwarding of TRILL Data
packets or TRILL IS-IS packets. It only affects ingressing and
egressing native frames.

An Appointed Forwarder for a link is inhibited for VLAN-x if:

1. its DRB inhibition timer for that link is not expired, or

2. its root bridge change inhibition timer for that link is not
expired, or

3. its VLAN inhibition timer for that link covering VLAN-x is not
expired.

If a VLAN-x Appointed Forwarder for a link is inhibited and receives
a TRILL Data packet whose encapsulated frame would normally be
egressed to that link in VLAN-x, it decapsulates the native frame as
usual. However, it does not output it to, or queue it for, that
link, although, if appropriate (for example, the frame is multi-
destination),
multi-destination), it may output it to, or queue it for, other
links.

If a VLAN-x Appointed Forwarder for a link is inhibited and receives
a native frame in VLAN-x that would normally be ingressed from that
link, the native frame is ignored ignored, except for address learning.

A TRILL switch with one or more unexpired inhibition timers, possibly
including an unexpired inhibition timer covering VLAN-x, is still
required to indicate in TRILL Hellos it sends on VLAN-x whether or
not it is Appointed Forwarder for VLAN-x for the port on which it
sends the Hello.

3.2

3.2. Root Bridge Change Inhibition Optimizations

The subsections below specify three optimizations that can reduce the
inhibition time of an RBridge port under certain circumstances for
changes in the root Bridge ID [802.1Q] being received by that port
and thus decrease any transient interruption in end station end-station service
due to inhibition. TRILL switches MAY implement these optimizations.
In the

INTERNET-DRAFT TRILL: Appointed Forwarders first two optimizations, inhibition can be eliminated entirely
under some circumstances. These optimizations are a bit heuristic in
that with some unlikely multiple changes in a bridged LAN that occur
simultaneously
simultaneously, or nearly so so, the optimizations make transient
looping more likely.

3.2.1

3.2.1. Optimization for Change to Lower Priority

Assume that the root Bridge ID being received on an RBridge port
changes to a new root Bridge ID with lower priority and a different
root Bridge MAC address due to a single change in the bridged LAN.
There are two possible reasons for this: (1) the

1. The bridged LAN to which the port is connected has partitioned
into two or more parts due to link failure or otherwise, and the
port is connected to a part that does not contain the original
root bridge; (2) the bridge.

2. The original root bridge has been reconfigured to have a lower priority
priority, and a new root has taken over.

Both of these scenarios are safe conditions that do not require
inhibition.

3.2.2

3.2.2. Optimization for Change to Priority Only

Assume that the root Bridge ID changes due to a single change in the
bridged LAN but only the explicit priority portion of it changes.
This means that the 48-bit MAC address portion of the root Bridge ID
is unchanged so and the root bridge has been reconfigured to have a
different priority but priority. Thus, the same bridge is root root, and there has been no a topology change.
change is not indicated. Thus, it is safe to ignore this sort of
root Bridge ID change and not invoke the inhibition mechanism.

3.2.3 Settling

3.2.3. Optimizing the Detection Optimization

The of Completed Settling

A dangerous case is the merger of bridged LANs that had been separate
TRILL links in the same campus. In general, these links may have had
different Appointed Forwarders on them for the same VLAN. Without
inhibition, after the merger, you could have loops involving those VLANs.

(Only VLANs could occur after the merger.

Only native frames egressed and ingressed by RBridges are a potential
problem. TRILL data Data packets are either

1. individually addressed (TRILL Header M bit = 0) and will be
ignored if delivered to any incorrect TRILL switch ports, ports or

2. multicast (TRILL Header M bit = 1), in which case the Reverse Path
Forwarding Check discards any copies delivered to incorrect TRILL
switch ports. Thus

Thus, there is no need for inhibition to affect the sending or
receiving of TRILL data packets Data packets, and inhibition does not do so.)

INTERNET-DRAFT TRILL: Appointed Forwarders so.

However, root bridge change inhibition is only needed until TRILL
Hellos have been exchanged on the merged bridged LAN. Hellos
indicate Appointed Forwarder status and, in general, after an
exchange of Hellos the new merged bridged LAN link will, if
necessary, be rendered TRILL loop safe by VLAN inhibition so that
root bridge change inhibition is not no longer needed.

TRILL switches are required to advertise in their link state the IDs
of the root Bridge IDs they can see. If an RBridge port sees a
change in root Bridge ID from Root1 to Root2, it is safe to terminate
root bridge change inhibition on that port as soon as Hellos have
been received on the port from all RBridges that can see Root1 or Root2
Root2, except any such RBridge that is no longer reachable.

In further detail, when a change from Root1 to Root2 is noticed at a
port of RB1, RB1 associates with that port a list of all of the
reachable RBridges, other than itself, that had reported in their LSP
LSPs that they could see either Root1 or Root2. It then removes from
this list any RBridge that becomes unreachable from RB1 or from which
it has received a Hello on that port. If there is a subsequent
change in root Bridge ID being received before this list is empty,
say to Root7, then those RBridges reporting in their LSP LSPs that they
can see Root7 are added to the list. Root bridge change inhibition
can be terminated for the port as soon as either the timeout is reach
reached or this list of RBridges is empty.

If the optimizations described in Sections 3.2.1 and/or 3.2.2 are in
effect at an RBridge port and indicate that no inhibition is needed,
then the mechanism described in this section is not needed either.

INTERNET-DRAFT TRILL: Appointed Forwarders

4. Optional TRILL Hello Reduction

If a network manager has sufficient confidence that they know the
configuration of bridges, ports, and the like, within an Ethernet
link, they may be able to reduce the number of TRILL Hellos sent on
that link by sending Hellos in fewer VLANs; VLANs -- for example, if all
TRILL switches on the link will see all Hellos without VLAN
constraints. However, because adjacencies are established in the
Designated VLAN, an RBridge MUST always attempt to send Hellos in the
Designated VLAN.

Hello reduction makes TRILL less robust in the face of decreased VLAN
connectivity within a link, such as partitioned VLANs, VLANs disabled
on ports, or disagreement over the Designated VLAN; however, as long
as all RBridge ports on the link are configured for the same
Desired Designated VLAN, VLAN [RFC6325], can see each other's frames in
that VLAN, and utilize the mechanisms specified below to update VLAN
inhibition timers, operations will be safe. (These considerations
do not arise on links between RBridges that are configured as point-to-point
point to point, since, in that case, each RBridge sends
point-to-point Hellos, other TRILL IS-IS PDUs, and TRILL Data frames
only in what it believes to be the Designated VLAN of the link
(although it may send them un-
tagged) untagged) and no native frame end-station
service is provided. Thus, for such links, there is no reason to
send Hellos in any other VLAN other than the Designated VLAN.)

The provision for a configurable set of "Announcing VLANs", as
described in Section 4.4.3 of [RFC6325], provides a mechanism in the
TRILL base protocol for a reduction in TRILL Hellos.

To maintain loop safety in the face of occasional lost frames,
RBridge failures, link failures, new RBridges coming up on a link,
and the like, the inhibition mechanism specified in Section 3 is
still required. Strictly following Section 3, a VLAN inhibition
timer can only be set by the receipt of a Hello sent or received in
that VLAN. Thus, to safely send a reduced number of TRILL Hellos on
a reduced number of VLANs requires additional mechanisms to set the
VLAN inhibition timers at an RBridge, thus extending Section 3. RBridge. Two such mechanisms are mechanisms, specified below.
below, expand upon the mechanisms provided in Section 3. Support for
both of these mechanisms is indicated by a capability bit in the
PORT-TRILL-VER sub-TLV (Section 5.4 of [RFC7176]). It may be unsafe
for an RBridge to send TRILL Hellos on fewer VLANs than the set of
VLANs recommended in [RFC6325] on a link unless all its adjacencies
on that link (excluding those in the Down state [RFC7177]) indicate
support of these mechanisms and these mechanisms are in use.

1. An RBridge RB2 MAY include in any TRILL Hello an Appointed
Forwarders sub-TLV [RFC7176] appointing itself for one or more
ranges of VLANs. The Appointee Nickname field(s) in the self-
appointment
self-appointment Appointed Forwarder Forwarders sub-TLV MUST be the same as
the Sender Nickname in the Special VLANs and Flags sub-TLV in the

INTERNET-DRAFT TRILL: Appointed Forwarders
TRILL Hellos sent by RB2. This indicates that the sending RBridge
believes that it is Appointed Forwarder for those VLANs. An RBridge
receiving such a sub-TLV sets For each
of its an RBridge's VLAN inhibition timers for every VLAN in the block
or blocks listed in the Appointed Forwarders sub-TLV to sub-TLV, the maximum of RBridge
sets that timer to either (1) its current value and or (2) the Holding
Time of the Hello containing the sub-TLV. sub-TLV, whichever is longer.
This is backward compatible. That is, such sub-TLVs will have no
effect on any legacy receiving RBridge not implementing this
mechanism unless RB2, the sending RBridge, is the DRB (Designated RBridge) sending
Hellos on the Designated VLAN. If RB2 is the DRB, it MUST include
in the Hello all forwarder appointments, if any, for RBridges
other than itself on the link.

2. An RBridge MAY use the VLANs Appointed sub-TLV [RFC7176]. When
RB1 receives a VLANs Appointed sub-TLV in a TRILL Hello from RB2
on any VLAN, RB1 updates the VLAN inhibition timers for all the
VLANs that RB2 lists in that sub-TLV as VLANs for which RB2 is
Appointed Forwarder. Each such timer is updated to the maximum of (1) its
current value and or (2) the Holding Time of the TRILL Hello
containing the VLANs Appointed sub-TLV. sub-TLV, whichever is longer. This
sub-TLV will be an unknown sub-TLV to RBridges not implementing
it, and such RBridges will ignore it. Even if a TRILL Hello sent
by the DRB on the Designated VLAN includes one or more VLANs
Appointed sub- TLVs, sub-TLVs, as long as no Appointed Forwarders sub-TLVs
appear, the Hello is not required to indicate all forwarder
appointments.

Two different encodings are provided above to optimize the listing of
VLANs. Large blocks of contiguous VLANs are more efficiently encoded
with the Appointed Forwarders sub-TLV, and scattered VLANs are more
efficiently encoded with the VLANs Appointed sub-TLV. These
encodings may be mixed in the same Hello. The use of these sub-TLVs
does not affect the requirement that the "AF" AF bit in the Special VLANs
and Flags sub-TLV MUST be set if the originating RBridge believes
that it is Appointed Forwarder for the VLAN in which the Hello
is sent.

If the above mechanisms are used on a link, then each RBridge on the
link MUST send Hellos in one or more VLANs with such VLANs Appointed
sub-TLV(s) and/or self-appointment Appointed Forwarders sub-TLV(s),
and the "AF" AF bit is appropriately set such that no VLAN inhibition
timer will improperly expire unless three or more Hellos are lost.
For example, an RBridge could announce all VLANs for which it
believes that it is Appointed Forwarder in a Hello sent on the
Designated VLAN three times per Holding Time.

INTERNET-DRAFT TRILL: Appointed Forwarders

5. Multiple Ports on the Same Link

A TRILL switch may have multiple ports on the same link. Some of
these ports may be suspended due to MAC address duplication duplication, as
described in [RFC7177]. Suspended ports never ingress or egress
native frames.

If a TRILL switch has one or more non-suspended ports on a link and
those ports offer end station service, end-station service -- that is, those ports are not
configured as point-to-point or trunk ports, ports -- then that TRILL switch
is eligible to be an Appointed Forwarder for that link. It can
become Appointed Forwarder in the ways discussed in Section 2.

If a TRILL switch that is the Appointed Forwarder for VLAN-x on a
link has multiple non-suspended ports on that link, it may load share load-share
the task of ingressing and egressing VLAN-x native frames across
those ports however it chooses, as long as there is no case in which
a frame it egresses onto the link from one port can be ingressed on
another one of its ports, creating a loop. If the TRILL switch is
the Appointed Forwarder for multiple VLANs, a straightforward thing
to do would be to partition those VLANs among the ports it has on
the link.

INTERNET-DRAFT TRILL: Appointed Forwarders

6. Port-Shutdown Messages

A TRILL switch may note that one of its ports has failed failed, or it
may be about to shut down that port. If the port is on a link along
with ports of other TRILL switches, those TRILL switches will not
notice the port shutdown or failure using TRILL base protocol
mechanisms until there is a failure to receive a number of Hellos
from that port. This can take many seconds. Network topology
(adjacencies) and forwarder appointments can react more rapidly to
port shutdown or failure through explicit notification. As discussed
below, this notification SHOULD be provided through the Port-Shutdown
message.

6.1

6.1. Planned Shutdown and Hellos

A TRILL switch that is shutting down one of its ports P1 (say P1) soon
SHOULD reduce its Holding Time on that port, so that the shutdown
will be more rapidly noticed by adjacent RBridges that might not
support the
Port Shutdown Port-Shutdown message.

6.2

6.2. Port-Shutdown Message Structure

The Port-Shutdown Message message is an RBridge Channel Message message [RFC7178]
using RBridge Channel protocol Protocol number tbd5. 0x006. The payload specific to
the Channel Protocol
specific payload consists of a list of Port IDs (see
Section 4.4.2 of [RFC6325]) for the port or ports that have failed or
are being
shutdown shut down, as shown in the diagram below. Support for the Port Shutdown
Port-Shutdown message is advertised by simply advertising support for
its RBridge Channel
protocol Protocol in the RBridge Channel Protocols Sub-TLV sub-TLV
[RFC7176].

INTERNET-DRAFT TRILL: Appointed Forwarders

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
TRILL Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |A|C|M| RESV |F| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Inner.MacDA = All-Egress-RBridges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Inner.MacDA cont. (cont.) | Inner.MacSA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacSA cont. (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN Tag Ethertype=0x8100 | Priority=7, DEI=0, VLAN ID=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RBridge Channel Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Chan. Ethertype=0x8946| CHV=0 | Channel Protocol=tbd5 | Protocol=0x006|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Information specific to the Port-Shutdown Channel Protocol:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID K |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3

6.3. Port-Shutdown Message Transmission

For robustness, a TRILL switch sends a configurable number of copies
of Port-Shutdown messages separated by a configurable time interval.
The default number of copies is two, although this can be configured
as one copy or as three copies, and the default interval is
20 milliseconds (see Section 6.6). As with any adjacency critical "adjacency critical"
message, the Port-Shutdown Message message SHOULD be sent with the highest
priority, which is priority 7 7, and SHOULD NOT be marked as drop eligible.
"drop eligible".

If a failure of port P1 on RBridge RB2 is detected by RB2, then the
Port-Shutdown message announcing this failure is sequentially unicast
through the rest of the TRILL campus to all RBridges (1) with which
P1 had an adjacency and which (2) that are advertising support for the
Port-Shutdown RBridge Channel protocol.

INTERNET-DRAFT TRILL: Appointed Forwarders Protocol.

If a port shutdown is planned within one 1 second, then the TRILL switch
ceases to send Hellos out of the port being shut down and either
(1) sends the Port-Shutdown message to RBridge ports on the link
advertising support of the Port-Shutdown RBridge Channel protocol, Protocol or
(2) broadcasts the Port-Shutdown message announcing this event
through the port as follows:

- The Outer.MacDA is the All-RBridges multicast address.

- If an outer VLAN tag is present, it specifies the designated Designated VLAN
for the link, SHOULD specify priority 7, and SHOULD NOT specify drop eligible.
"drop eligible".

- In the TRILL Header, the egress nickname is All-RBridges All-RBridges, and the
M bit in the TRILL Header is set to 0.

- In the RBridge Channel Header, the MH and NA bits are zero.

There is no need for a special message to indicate that a port P1 has
come back up or that a shutdown has been "cancelled". "canceled". This is
indicated by simply sending Hellos out of port P1.

6.4

6.4. Port-Shutdown Message Reception

When a TRILL switch RB1 receives a Port-Shutdown message message, RB1 checks
that
to see if the ingress nickname specifies some TRILL switch RB2 with
which RB1 has one or more adjacencies. If so, it drops those
adjacencies that are to RB2 ports whose Port IDs are listed in the
Port-Shutdown message. There could be more than one if RB2 had
multiple ports on the link that are going down.

If RB1 is the DRB and this eliminates all adjacencies on a link
between the DRB and RB2, then, for all VLANs whose ingress/egress was
being handled by RB2, the DRB either starts acting an as Appointed
Forwarder or appoints some new TRILL switch with which it has
adjacency as Appointed Forwarder.

6.5

6.5. Port-Shutdown Message Security

Port-Shutdown messages can be secured through the use of the RBridge
Channel
Tunnel Header Extension security features feature [RFC7978].

6.6

6.6. Port-Shutdown Configuration

There are two Port-Shutdown configuration parameters (see parameters, as listed
below. Section
6.3):

INTERNET-DRAFT TRILL: Appointed Forwarders 6.3 provides details regarding their use.

Parameter Default Range
--------- --------- -------
--------------- ---------------- ---------------------
PShutdownRepeat 2 1-3
PShutdownDelay 20ms 0-1000 20 milliseconds 0-1,000 milliseconds

INTERNET-DRAFT TRILL: Appointed Forwarders

7. FGL-VLAN Mapping Consistency Checking

TRILL switches support 24-bit Fine Grained Fine-Grained Labels as specified in
[RFC7172]. Basically Basically, a VLAN ID in native traffic between an edge
TRILL switch and an end station is mapped from/to an FGL as an
Inner.Label in TRILL Data packets. Since the Appointed Forwarder for
a VLAN will be ingressing and egressing such native traffic, the
mapping configured at the Appointed Forwarder is the mapping
performed.

However, the Appointed Forwarder for VLAN-x on a link can change for
reasons discussed elsewhere in this document. Thus Thus, all
TRILL switches on a link that are configured with a an FGL-VLAN mapping
SHOULD be configured with the same mapping. Otherwise Otherwise, traffic might
unpredictably jump from one FGL to another when the Appointed
Forwarder changes. TRILL switches SHOULD advertise their mapping on
the link using the FGL-VLAN-Bitmap and FGL-VLAN-Pairs APPsub-TLVs
(Sections 10.4 and 10.5) so that consistency checking can be
automated.

A TRILL switch SHOULD compare the FGL-VLAN mappings that it sees
advertised by other TRILL switches on a link with its own and alert
the network operator if they are inconsistent. Inconsistent "Inconsistent" means
that (1) one TRILL switch maps FGL-z to VLAN-x while another maps
FGL-z to VLAN-y or (2) one TRILL switch maps VLAN-x to FGL-w while
another maps VLAN-x to FGL-z, all on the same link.

Depending on how the network is being managed, a transient
inconsistency may not be a problem. Thus Thus, the network operator
SHOULD NOT be alerted unless the inconsistency persists for a period
of time
which that defaults to the TRILL switch's Holding Time and is
configurable to between zero 0 seconds and 2**16 - 1 seconds seconds,
where 2**16 - 1 is a special value and indicates that such alerts
are disabled.

INTERNET-DRAFT TRILL: Appointed Forwarders

8. Support of E-L1CS

All TRILL switches MUST support the E-L1CS flooding scope [RFC7356],
E-L1FS flooding scope
Extended Level 1 Flooding Scope (E-L1FS) [RFC7780], and base LSPs
[IS-IS]. It will be apparent to any TRILL switch on a link if any
other TRILL switch on the link is a legacy implementation not
supporting E-L1CS because, as stated in [RFC7780], all TRILL switches
MUST include a Scoped Scope Flooding Support TLV [RFC7356] in all TRILL
Hellos they send. This support of E-L1CS increases the amount of
information from each TRILL switch that can be synchronized on the
link, compared with the information capacity of Hellos, by several
orders of magnitude.

For robustness, E-L1CS PDUs (FS-LSP fragments, E-L1CS FS-CSNPs, FS-CSNPs
(Flooding Scope Complete Sequence Number PDUs) [RFC7356], and E-L1CS FS-PSNPs)
FS-PSNPs (Flooding Scope Partial Sequence Number PDUs) [RFC7356])
MUST NOT exceed 1470 1,470 bytes in length; however, any such E-L1CS PDU
that is received that is longer than 1470 1,470 bytes is processed
normally.

As with any type of IS-IS LSP, FS-LSPs are identified by the
System ID of the originating router (TRILL switch) and the
fragment number. In particular, there is no port identifier in the
header of a an E-L1CS PDU. Thus Thus, a TRILL switch RB1 with more than one
non-suspended port on a link (Section 5) transmitting such a PDU MAY
transmit it out of any one or more of such ports. RB1 will generally
receive such a PDU that other TRILL switches send on all of RB1's
ports on the link. In addition, with multiple ports on the link, it
will receive any such PDU that it sends on the ports it has on the
link other than the transmitting port.

8.1 Backwards

8.1. Backward Compatibility

Future TRILL specifications making use of E-L1CS MUST specify how
situations involving a TRILL link will be handled when one or more
TRILL switches attached to that link support E-L1CS and one or more
do not.

INTERNET-DRAFT TRILL: Appointed Forwarders

9. Security Considerations

This document provides improved documentation of the TRILL Appointed
Forwarder mechanism. It does not change the security considerations
of the TRILL base protocol as described in Section 6 of [RFC6325].

The Port-Shutdown messages specified in Section 6 are sent using the
RBridge Channel facility [RFC7178]. Such messages SHOULD be secured
through the use of the RBridge Channel Header Extension [RFC7978].
If they are not adequately secured, they are a potential denial of
service
denial-of-service vector.

The E-L1CS FS-LSPs added by Section 6 8 are a type of IS-IS PDU
[RFC7356]. As such, they are securable through the addition of
Authentication TLVs [RFC5310] in the same way as Hellos or other IS-
IS
IS-IS PDUs.

INTERNET-DRAFT TRILL: Appointed Forwarders

10. Code Points and Data Structures

This section provides IANA Considerations considerations for this document and
specifies the structure structures of the Appointment Bitmap, Appointment List, AppointmentBitmap, AppointmentList,
VLAN-FGL Mapping Bit Map, and VLAN-FGL Mapping Pairs APPsub-TLVs.
These APPsub-TLVs appears appear within a TRILL GENINFO TLV [RFC7357] in E-
L1CS
E-L1CS FS-LSPs [RFC7356].

10.1

10.1. IANA Considerations

IANA is requested to assign has assigned four new APPsub-TLV type codes from the range below
255 and enter entered them in the "TRILL APPsub-TLV Types under IS-IS TLV
251 Application Identifier 1" Registry registry as follows:

Type Name Reference
---- ----------------- ---------------
tbd1 ---------
17 AppointmentBitmap [this document]
tbd2 [RFC8139]
18 AppointmentList [this document]
tbd3 [RFC8139]
19 FGL-VLAN-Bitmap [this document]
tbd4 [RFC8139]
20 FGL-VLAN-Pairs [this document] [RFC8139]

IANA is requested to assign has assigned a new RBridge Channel protocol Protocol number in the range
assigned by Standards Action [RFC5226] and update updated the "RBridge
Channel Protocols" registry as follows:

Protocol Description Reference
-------- -------------- ---------
tbd5 Port Shut-Down [this document]
0x006 Port-Shutdown [RFC8139]
IANA is requested to update has updated the reference for the "Hello reduction support" bit
in the "PORT-TRILL-VER Sub-TLV Capability Flags" registry on the TRILL Parameters IANA web page to refer to
this document.

10.2 Appointment Bitmap

10.2. AppointmentBitmap APPsub-TLV

The Appointment Bitmap AppointmentBitmap APPsub-TLV provides an efficient method for a
TRILL switch to indicate which TRILL switches it appoints as
forwarders for which VLAN IDs when those VLAN IDs are relatively
compact, that
compact (that is, they do not span a large numeric range. range). Such an
appointment is only effective when the appointing TRILL switch is
the DRB.

INTERNET-DRAFT TRILL: Appointed Forwarders

o Type: APPsub-TLV type, set to AppointmentBitmap sub-TLV tbd1. 17.

o Length: 4 + size of bit map in bytes. If Length is less than 4,
the APPsub-TLV is corrupt and MUST be ignored.

o Appointee Nickname: The nickname of the TRILL switch being
appointed a as forwarder.

o RESV: 4 bits that MUST be sent as zero and ignored on receipt.

o Starting VLAN ID: The smallest VLAN ID to which the bits in the
Bit Map correspond.

o Bit Map: A bit map of the VLANs for which the TRILL switch with
appointee nickname
Appointee Nickname is appointed as the forwarder. The size of the
bit map is length minus 4. If the size of the bit map is zero,
no appointments are made.

Each bit in the Bit Map corresponds to a VLAN ID. Bit 0 is for the
VLAN whose ID appears in the Starting VLAN ID field. Bit 1 is for
that VLAN ID plus 1 (treating VLAN IDs as unsigned integers) and
so on on, with Bit N generally being Starting VLAN ID plus N.
VLAN 0x000 and VLAN 0xFFF 0xFFF, or any larger ID ID, are invalid and are
ignored.

If the Appointment Bitmap AppointmentBitmap APPsub-TLV is originated by the DRB on a
link, it appoints the TRILL switch whose nickname appears in the
Appointee Nickname field for the VLAN IDs corresponding to 1 bits in
the Bit Map and revokes any Hello appointment of that TRILL switch
for VLANs corresponding to 0 bits in the Bit Map.

10.3 Appointment List

10.3. AppointmentList APPsub-TLV

The Appointment List AppointmentList APPsub-TLV provides a convenient method for a
TRILL switch to indicate which TRILL switches it appoints as

INTERNET-DRAFT TRILL: Appointed Forwarders
forwarders for which VLAN IDs. Such an appointment is only effective
when the appointing TRILL switch is the DRB.

o Type: APPsub-TLV type, set to AppointmentList sub-TLV tbd2. 18.

o Length: 2+2*k. 2 + 2 * k. If Length is not an even number, the
APPsub-TLV is corrupt and MUST be ignored.

o Appointee Nickname: The nickname of the TRILL switch being
appointed a as forwarder.

o RESV: 4 bits that MUST be sent as zero and ignored on receipt.

o VLAN ID: A 12-bit VLAN ID for which the appointee is being
appointed as the forwarder.

Type and Length are 2 bytes bytes, because these are extended FS-LSPs.

This APPsub-TLV, when originated by the DRB, appoints the TRILL
switch with Appointee Nickname to be the Appointed Forwarder for the
VLAN IDs listed.

10.4 FGL-VLAN Mapping Bitmap

10.4. FGL-VLAN-Bitmap APPsub-TLV

The FGL-VLAN Mapping Bitmap FGL-VLAN-Bitmap APPsub-TLV provides a method for a TRILL switch
to indicate the FGL mappings of FGLs to VLAN ID mappings IDs that it is configured to
perform when egressing and ingressing native frames.

The coding is efficient when both of the following apply:

- the VLAN IDs are compact, that compact (that is, they do not span a large
numeric range, range), and

- the FGLs and VLANs VLAN IDs are paired in a monotonically increasing
fashion.

INTERNET-DRAFT TRILL: Appointed Forwarders

o Type: APPsub-TLV type, set to VLAN-FGL-Bitmap sub-TLV tbd3. 19.

o Length: 5 + size of bit map in bytes. If Length is less than 5,
the APPsub-TLV is corrupt and MUST be ignored.

o RESV: 4 bits that MUST be sent as zero and ignored on receipt.

o Starting VLAN ID: Initial VLAN ID for the mapping information as
discussed below.

o Starting FGL: Fine Grained Fine-Grained Label [RFC7172] [RFC7172].

o Bit Map: Map of bits for VLANs to FGL VLAN-ID-to-FGL mappings. The size of the
bit map is Length minus 5. If the size of the bit map is zero,
no mappings are indicated.

Each bit in the Bit Map corresponds to a VLAN ID and to an FGL.
Bit 0 is for the VLAN whose ID appears in the Starting VLAN ID field
and the
Fine Grained Fine-Grained Label that appears in the FGL field. Bit 1 is
for that VLAN ID plus 1 and that FGL plus 1 (treating VLAN IDs and
FGLs as unsigned integers) and so on on, with Bit N generally being
Starting VLAN ID plus N and FGL plus N.

If a Bit Map bit is a 1, it indicates that the advertising TRILL
switch will map between the corresponding VLAN ID and FGL on
ingressing native frames and egressing TRILL Data packets if it is
Appointed Forwarder for the VLAN. If a Bit Map bit is a 0, it does
not indicate any configured mapping of the VLAN ID to FGL mapping. the FGL.
However, VLAN ID 0x000 and VLAN ID 0xFFF or any larger ID are invalid
invalid, and FGLs larger than 0xFFFFFF are invalid; any Bit Map bits
that corresponds correspond to an illegal VLAN ID or an illegal FGL is are ignored.

INTERNET-DRAFT TRILL: Appointed Forwarders

10.5 FGL-VLAN Mapping Pairs

10.5. FGL-VLAN-Pairs APPsub-TLV

The FGL-VLAN Mapping Pairs FGL-VLAN-Pairs APPsub-TLV provides a method for a TRILL switch to
indicate a list of FGL the mappings of FGLs to VLAN ID mappings IDs that it is
configured to perform when egressing and ingressing native frames.

o Type: APPsub-TLV type, set to VLAN-FGL-Pairs sub-TLV tbd4. 20.

o Length: 5*k. 5 * k. If Length is not a multiple of 5, the APPsub-TLV
is corrupt and MUST be ignored.

o RESV: 4 bits that MUST be sent as zero and ignored on receipt.

o VLAN ID: 12-bit VLAN label.

o FGL: Fine Grained Fine-Grained Label [RFC7172] [RFC7172].

Each Mapping RECORD indicates that the originating TRILL switch is
configured to map between the FGL and VLAN given on egressing and
ingressing native frames. However, VLAN ID 0x000 and VLAN ID 0xFFF
are invalid; any Mapping RECORD that corresponds to an illegal
VLAN ID is ignored.

INTERNET-DRAFT TRILL: Appointed Forwarders

11. Management Considerations

This document primarily adds optional enhancements or optimizations optimizations.
The only configuration parameters specified in this document are the
number and frequency of copies sent of the Port Shutdown message Port-Shutdown messages sent, as
specified in Section 6.6.

TRILL switch support of SNMPv3 is provided in the TRILL base protocol
document [RFC6325] and [RFC6325]. MIBs have been specified in [RFC6850] and
[RFC7784]
[RFC7784], but they do not include the configurable parameters
specified herein. It is anticipated that YANG modules will be
specified for TRILL.

INTERNET-DRAFT TRILL: Appointed Forwarders

12. References

12.1. Normative References

[802.1Q] - IEEE 802.1, IEEE, "IEEE Standard for Local and metropolitan area
networks - Virtual
networks--Bridges and Bridged Local Area Networks",
IEEE Std 802.1Q-2014, 19 December 2014. DOI 10.1109/ieeestd.2014.6991462,
<http://ieeexplore.ieee.org/
servlet/opac?punumber=6991460>.

[IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System
to Intermediate System Intra-Domain Routeing Exchange
Protocol for use in Conjunction with the Protocol for
Providing the Connectionless-mode Network Service
(ISO 8473)", November 2002.

[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <http://www.rfc-
editor.org/info/rfc6325>.
<http://www.rfc-editor.org/info/rfc6325>.

[RFC6329] - Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg,
A., and P. Unbehagen, "IS-IS Extensions Supporting
IEEE 802.1aq Shortest Path Bridging", RFC 6329,
DOI 10.17487/RFC6329, April 2012, <http://www.rfc-
editor.org/info/rfc6329>.
<http://www.rfc-editor.org/info/rfc6329>.

[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>.

[RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
D., and A. Banerjee, "Transparent Interconnection of Lots
of Links (TRILL) Use of IS-IS", RFC 7176,
DOI 10.17487/RFC7176, May 2014,
<http://www.rfc-editor.org/info/rfc7176>.

[RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and
V. Manral, "Transparent Interconnection of Lots of Links
(TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177,
May 2014, <http://www.rfc-
editor.org/info/rfc7177>. <http://www.rfc-editor.org/info/rfc7177>.

[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>.
<http://www.rfc-editor.org/info/rfc7178>.

[RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
Scope Link State PDUs (LSPs)", RFC 7356,
DOI 10.17487/RFC7356, September 2014,
<http://www.rfc-editor.org/info/rfc7356>.

INTERNET-DRAFT TRILL: Appointed Forwarders

[RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.
Stokes, "Transparent Interconnection of Lots of Links
(TRILL): End Station Address Distribution Information
(ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357,
September 2014, <http://www.rfc-
editor.org/info/rfc7357>. <http://www.rfc-editor.org/info/rfc7357>.

[RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., 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>.

[RFC7978] - Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent
Interconnection of Lots of Links (TRILL): RBridge Channel
Header Extension", RFC 7978, DOI 10.17487/RFC7978,
September 2016, <http://www.rfc-editor.org/info/rfc7978>.

[RFC7981] - Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
for Advertising Router Information", RFC 7981,
DOI 10.17487/RFC7981, October 2016, <http://www.rfc-
editor.org/info/rfc7981>.
<http://www.rfc-editor.org/info/rfc7981>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
<http://www.rfc-editor.org/info/rfc8174>.

12.2. Informative References

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.

[RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, DOI 10.17487/RFC5310,
February 2009, <http://www.rfc-editor.org/info/rfc5310>.

[RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F.
Hu, "Routing Bridges (RBridges): Appointed Forwarders",
RFC 6439, DOI 10.17487/RFC6439, November 2011,
<http://www.rfc-editor.org/info/rfc6439>.

[RFC6850] - Rijhsinghani, A. and K. Zebrose, "Definitions of Managed
Objects for Routing Bridges (RBridges)", RFC 6850,
DOI 10.17487/RFC6850, January 2013, <http://www.rfc-
editor.org/info/rfc6850>.
<http://www.rfc-editor.org/info/rfc6850>.

[RFC7379] - Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai,
"Problem Statement and Goals for Active-Active Connection
at the Transparent Interconnection of Lots of Links
(TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379,
October 2014, <http://www.rfc-
editor.org/info/rfc7379> <http://www.rfc-editor.org/info/rfc7379>.

[RFC7784] - Kumar, D., Salam, S., and T. Senevirathne, "Transparent
Interconnection of Lots of Links (TRILL) Operations,
Administration, and Maintenance (OAM) MIB", RFC 7784,
DOI 10.17487/RFC7784, February 2016, <http://www.rfc-
editor.org/info/rfc7784>.

INTERNET-DRAFT TRILL: Appointed Forwarders

Acknowledgements
<http://www.rfc-editor.org/info/rfc7784>.

Appendix A. VLAN Inhibition Example

The following per-VLAN inhibition timers (or the equivalent) are hereby thanked for their contributions to this
document:

Spencer Dawkins, Shawn M Emery, Stephen Farrell, Joel Halpern, Sue
Hares, Christer Holmberg, Gayle Noble, Alvaro Retana, Dan
Romascanu, Mingui Zhang

The following were acknowledged and thanked by in [RFC6439] or were
an author of [RFC6439], the predecessor to this document:

Ron Bonica, Stewart Bryant, Linda Dunbar, Les Ginsberg, Erik
Nordmark, Radia Perlman, Dan Romascanu, and Mike Shand.

INTERNET-DRAFT TRILL: Appointed Forwarders

Authors' Addresses

Donald 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-56622310
EMail: liyizhou@huawei.com

Mohammed Umair
IPinfusion

EMail: mohammed.umair2@ipinfusion.com

Ayan Banerjee
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134 USA

Phone: +1-408-333-7149
EMail: ayabaner@cisco.com

Fangwei Hu
ZTE Corporation
889 Bibo Road
Shanghai 201203
China

Phone: +86-21-68896273
EMail: hu.fangwei@zte.com.cn

INTERNET-DRAFT TRILL: Appointed Forwarders

Appendix A: VLAN Inhibition Example

The per-VLAN inhibition timers (or the equivalent) are needed needed to be
loop safe in the case of misconfigured bridges on a link.

For a simple example, assume that RB1 and RB2 are the only RBridges
on the link, that RB1 is higher priority to be the DRB, and that they
both want VLAN 1 (the default) to be the Designated VLAN. However,
there is a bridge between them configured so that RB1 can see all the
frames sent by RB2 but none of the frames from RB1 can get through
to RB2.

Both will think they are the DRB. DRB: RB1 because it is higher priority
even though it sees the Hellos from RB2, and RB2 because it doesn't
see the Hellos from RB1 and therefore thinks it is highest priority.

Say RB1 chooses to act as Appointed Forwarder for VLANs 2 and 3 while
RB2 chooses to act as Appointed Forwarder for VLANs 3 and 4. There
is no problem with VLANs 2 and 4 4, but if you do not do something
about it, you could have a loop involving VLAN 3. RB1 will see the
Hellos that RB2 issues on VLAN 3 declaring itself Appointed
Forwarder, so RB1 will be inhibited on VLAN 3. RB2 does not see the
Hellos issued by RB1 on VLAN 3, so RB2 will become uninhibited and
will handle VLAN 3 native traffic.

However, this situation may change. RB2 might crash, the bridge
might crash, or RB2 might be reconfigured so it no longer tried to act
as Appointed Forwarder for VLAN 3, or other issues may occur. So,
RB1 has to maintain a VLAN 3 inhibition timer, and if it sees
no Hellos from any other RBridge on the link claiming to be Appointed
Forwarder for VLAN 3 for a long enough time, then RB1 becomes
uninhibited for that VLAN on the port in question and can handle end
station
end-station traffic in VLAN 3.

INTERNET-DRAFT TRILL: Appointed Forwarders

Appendix B: Changes to RFCs 6325, 6439, 7177

This document updates [RFC6325], obsoletes [RFC6439], B. Multi-Link VLAN Mapping Loop Example

Assume that RBridges RB1 and updates
[RFC7177].

Change to [RFC6325], the TRILL base protocol, is as follows:

Addition of mandatory support for E-L1CS FS-LSPs.

Changes from [RFC6439], which this document obsoletes, RB2 have ports P1 and P2, respectively,
that are as
follows:

1. Specify APPsub-TLVs and procedures to be used in E-L1CS FS-LSP
forwarder appointments.

2. Incorporate updates to [RFC6439] that appeared in Section 10 of
RFC 7180, which has been obsoleted by [RFC7780]. They appear
primarily in Section 4 of this document.

3. Add optional FGL-VLAN consistency check feature including
specification of APPsub-TLVs.

4. Delete references to the draft-ietf-trill-rbridge-vlan-mapping
draft, which has been dropped by the TRILL WG.

5. Addition of the Port Shutdown message.

6. Eliminate requirement that the DRB not send appointments in
Hellos until its DRB inhibition timer has expired. This was an
unnecessary safety precaution that is pointless given that
appointments in E-L1CS FS-LSPs are immediately visible.

7. Addition of three optional methods to optimize (reduce)
inhibition time under various circumstances.

8. Editorial changes.

Changes to [RFC7177] are as follows:

As provided in Section 6, TRILL switches SHOULD treat the
reception of a Port-Shutdown RBridge Channel message from RB1
listing port P1 as if it were an event A3 as specified in
[RFC7177] resulting in transition of any adjacency to P1 to the
Detect state.

INTERNET-DRAFT TRILL: Appointed Forwarders

Appendix C: Multi-Link VLAN Mapping Loop Example

Assume that RBridges RB1 and RB2 have ports P1 and P2, respectively,
that are both on link L1 both on Link L1 and that RBridges RB3 and RB4 have ports P3
and P4, respectively, that are both on Link L2. Assume further that
P1 and P3 are Appointed Forwarder Forwarders for VLAN-x and P2 and P4 are
Appointed Forwarder Forwarders for VLAN-y. This situation is shown in the
figure below.

+ - - - - - - - - - - - - - - - - - - - - - +
| |
| TRILL network |
| |
| +---+ +---+ +---+ +---+ |
+ -|RB1|- -|RB2|- - - - - - -|RB3|- -|RB4|- +
+---+ +---+ +---+ +---+
P1| P2| P3| P4|
| | | |
|x |y |x |y
| +-+ | | +-+ |
L1 ---+---|M|---+--+--- L2 ---+---|M|---+---
+-+ | +-+
+---+
|ES1|
+---+

Further assume that L1 and L2 are each bridged LANs that include a
device M, presumably a bridge, that maps VLAN-x into VLAN-y and
VLAN-y into VLAN-x.

If end station ES1 originated a broadcast or other multi-destination
frame in VLAN-y, it would be ingressed by RB2. (The frame would also
be mapped to VLAN-x and ingressed by RB1 RB1, but we initially ignore
that.) RB2 will flood the resulting TRILL Data packet through the
campus
campus, and, at least in the broadcast and unknown unicast cases,
it will get to RB4 RB4, where it will be egressed to L2. Inside L2, this
broadcast frame is mapped to VLAN-x and then ingressed by RB3. RB3
then floods the resulting TRILL Data packet through the campus, this
time with an Inner.VLAN of VLAN-x, as a result of which it will be
egressed by RB1 into L1. Inside L1, it will be mapped back to VLAN-y
and then ingressed by RB2 RB2, completing the loop. The packet will loop
indefinitely, because in native form on L1 and L2 it has no TRILL hop
count,
Hop Count, and an indefinitely large number of copies will be
delivered to ES1 and any other end station so situated. The same
problem would occur even if P1 and P2 were on the same RBridge and/or
P3 and P4 were on the same RBridge. Actually, because the original
frame was also mapped to VLAN-x inside L1 and ingressed by RB1, there
are two copies looping around in opposite directions.

The use of Fine Grained Fine-Grained Labels [RFC7172] complicates but does not

INTERNET-DRAFT TRILL: Appointed Forwarders
essentially change the potential problem.

This example shows why VLAN mapping between Appointed Forwarder ports
on a TRILL link is loop unsafe. When such a situation is detected,
the DRB on the link changes Appointed Forwarders as necessary to
assure that a single RBridge port is Appointed Forwarder for all
VLANs involved in mapping. This change makes the situation
loop safe.

INTERNET-DRAFT TRILL: Appointed Forwarders

Appendix Z: Change Record

This appendix summarizes changes between versions of this draft.

RFC Editor: Please delete this

Appendix before publication.

Initial WG version -00

From -00 to -01

Primarily editorial changes based on review by Gayle Noble.

From -01 to -02

Primarily editorial changes based on RTGDIR QA review by Joel
Halpern.

From -03 to -04

Update references and incorporate changes from SECDIR review.

From -04 to -05 C. Changes to resolve GENART, RTG DIR, OPS DIR, and IESG comments.

INTERNET-DRAFT TRILL: Appointed Forwarders

This document is subject to BCP 78 updates [RFC6325], obsoletes [RFC6439], and the IETF Trust's Legal
Provisions Relating updates
[RFC7177].

The change to IETF Documents
(http://trustee.ietf.org/license-info) in effect on [RFC6325], the date TRILL base protocol, is as follows:

Addition of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect mandatory support for E-L1CS FS-LSPs.

Changes to this document. Code Components extracted from [RFC6439], which this document must
include Simplified BSD License text obsoletes, are as described in Section 4.e follows:

1. Specification of
the Trust Legal Provisions APPsub-TLVs and are provided without warranty as
described procedures to be used in the Simplified BSD License. The definitive version
E-L1CS FS-LSP forwarder appointments.

2. Incorporation of
an IETF Document is updates to [RFC6439] that published by, or under the auspices of, the
IETF. Versions appeared in Section 10
of IETF Documents that are published RFC 7180, which has been obsoleted by third parties, [RFC7780]. They appear
primarily in Section 4 of this document.

3. Addition of an optional FGL-VLAN consistency check feature,
including those that are translated into other languages, should not
be considered to be definitive versions specification of IETF Documents. The
definitive APPsub-TLVs.

4. Deletion of references to the October 2011 version of these Legal Provisions is that published by, or
under the auspices of, document
"RBridges: Campus VLAN and Priority Regions"
(draft-ietf-trill-rbridge-vlan-mapping), which has been dropped by
the IETF. Versions TRILL WG.

5. Addition of these Legal Provisions the Port-Shutdown message.

6. Elimination of the requirement that are published by third parties, including those the DRB not send appointments
in Hellos until its DRB inhibition timer has expired. This was an
unnecessary safety precaution that is pointless, given that
appointments in E-L1CS FS-LSPs are
translated into other languages, should not be considered to be
definitive versions of these Legal Provisions. For the avoidance immediately visible.

7. Addition of
doubt, each Contributor three optional methods (Section 3.2) to optimize
(reduce) inhibition time under various circumstances.

8. Editorial changes.

Changes to [RFC7177] are as follows:

As provided in Section 6, TRILL switches SHOULD treat the IETF Standards Process licenses each
Contribution that he or she makes
reception of a Port-Shutdown RBridge Channel message from RB1
listing port P1 as part if it were an event A3 as specified in
[RFC7177], resulting in transition of the IETF Standards
Process any adjacency to the IETF Trust pursuant P1 to the provisions of RFC 5378. No
language
Detect state.

Acknowledgments

The following are hereby thanked for their contributions to the contrary, or terms, conditions or rights that differ
from or this
document:

Spencer Dawkins, Shawn M. Emery, Stephen Farrell, Joel Halpern,
Sue Hares, Christer Holmberg, Gayle Noble, Alvaro Retana, Dan
Romascanu, and Mingui Zhang.

The following are inconsistent with thanked for their contributions to [RFC6439], the rights and licenses granted under
RFC 5378, shall have any effect and shall be null
predecessor to this document:

Ron Bonica, Stewart Bryant, Linda Dunbar, Les Ginsberg, Erik
Nordmark, Dan Romascanu, and void, whether
published or posted by such Contributor, or included with or in such
Contribution. Mike Shand.

We also thank Radia Perlman, who coauthored [RFC6439].

Authors' Addresses

Donald Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757
United States of America

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

Yizhou Li
Huawei Technologies
101 Software Avenue
Nanjing 210012
China

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

Mohammed Umair
IP Infusion

Email: mohammed.umair2@ipinfusion.com

Ayan Banerjee
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
United States of America

Phone: +1-408-333-7149
Email: ayabaner@cisco.com

Fangwei Hu
ZTE Corporation
889 Bibo Road
Shanghai 201203
China

Phone: +86-21-68896273
Email: hu.fangwei@zte.com.cn