Subject: Re: [trill] Advancing draft-eastlake-trill-rfc6327bis-00 to WG draft

From: Donald Eastlake <[email-masked]>
Date: Mon, 17 Jun 2013 11:43:03 -0400

There having been no objections, this draft is adopted as a WG draft.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Tue, May 28, 2013 at 11:59 PM, Donald Eastlake <[email-masked]> wrote:
> We plan to make draft-eastlake-trill-rfc6327bis-00 a working group
> draft unless there is significant opposition.
>
> Appendix A of this draft summarizes changes from RFC 6327.
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [email-masked]

---

From: gayle noble <[email-masked]>
Date: Tue, 25 Jun 2013 19:55:57 -0700

NOTE: [**]
is before every paragraph in which I attempted to make the English more
understandable to whoever might read it.

TRILL Working
Group
Donald Eastlake

INTERNET-DRAFT
Huawei

Obsoletes:
6327
Radia Perlman

Updates:
6325
Intel Labs

Intended status: Proposed
Standard
Anoop Ghanwani

Dell

Vishwas Manral

HP

Expires: December 16,
2013
June 17, 2013

TRILL: Adjacency

<draft-ietf-trill-rfc6327bis-00.txt>

Abstract

The IETF TRILL (TRansparent Interconnection of Lots of
Links)

protocol supports arbitrary link technologies between TRILL
switches

including point-to-point links and multi-access LAN (Local
Area

Network) links that can have multiple TRILL switches and end
stations

attached. TRILL uses IS-IS (Intermediate System to
Intermediate

System) routing. This document specifies the
establishment,

reporting, and termination of IS-IS adjacency between TRILL
switches,

also known as RBridges. It also concerns four other
link-local

aspects of TRILL: Designated RBridge (DRB) selection, MTU
(Maximum

Transmission Unit) testing, pseudonode creation, and BFD
(Bi-

Directional Forwarding Detection) session bootstrapping in
connection

with adjacency. State diagrams are included where
appropriate. This

document obsoletes RFC 6327 and updates RFC 6325.

Status of This Memo

This Internet-Draft is submitted to IETF in full conformance
with the

provisions of BCP 78 and BCP 79.

Distribution of this document is unlimited. Comments should
be sent

to the TRILL working group mailing list.

Internet-Drafts are working documents of the Internet
Engineering

Task Force (IETF), its areas, and its working groups.
Note that

other groups may also distribute working documents as
Internet-

Drafts.

Internet-Drafts are draft documents valid for a maximum of
six months

and may be updated, replaced, or obsoleted by other
documents at any

time.  It is inappropriate to use Internet-Drafts as
reference

material or to cite them other than as "work in
progress."

D. Eastlake, et
al
[Page 1]

INTERNET-DRAFT
TRILL: Adjacency

The list of current Internet-Drafts can be accessed at

http://www.ietf.org/1id-abstracts.html. The list of
Internet-Draft

Shadow Directories can be accessed at

http://www.ietf.org/shadow.html.

D. Eastlake, et
al
[Page 2]

INTERNET-DRAFT
TRILL: Adjacency

Table of Contents

1.
Introduction............................................4

1.1 Content and
Precedence.................................5

1.2 Terminology and
Acronyms...............................5

2. The TRILL Hello Environment and
Purposes................6

2.1 RBridge Interconnection by
Ethernet....................6

2.2 Handling Native
Frames.................................7

2.3 Zero or Minimal
Configuration..........................8

2.4 MTU
Robustness.........................................8

2.5 Purposes of the TRILL Hello
Protocol...................8

3. Adjacency State
Machinery..............................10

3.1 TRILL Hellos, Ports, and
VLANs........................10

3.2 Adjacency Table Entries and
States....................11

3.3 Adjacency and Hello
Events............................12

3.4 Adjacency State Diagram and
Table.....................15

3.5 Multiple Parallel
Links...............................16

3.6 Insufficient Space in Adjacency
Table.................17

4. LAN Ports and DRB
State................................18

4.1 Port Table Entries and DRB Election
State.............18

4.2 DRB Election
Events...................................19

4.2.1 DRB Election
Details................................20

4.2.2 Change in
DRB.......................................20

4.2.3 Change in Designated
VLAN...........................21

4.3 State Table and
Diagram...............................21

5. MTU
Matching...........................................23

6. BFD Enabled and BFD Session
Bootstrap..................25

7.
Pseudonodes............................................27

8. More TRILL Hello
Details...............................28

8.1 Contents of TRILL
Hellos..............................28

8.2 Transmitting TRILL
Hellos.............................29

8.2.1 TRILL Neighbor
TLVs.................................29

8.3 Receiving TRILL
Hellos................................30

9. Multiple Ports on the Same Broadcast
Link..............32

10. Security
Considerations...............................33

11. IANA
Considerations...................................33

Appendix A: Changes from
[RFC6327]........................34

Normative
References......................................35

Informative
References....................................35

Acknowledgements..........................................37

Authors'
Addresses........................................38

D. Eastlake, et
al
[Page 3]

INTERNET-DRAFT
TRILL: Adjacency

1. Introduction

The IETF TRILL (TRansparent Interconnection of Lots of Links)

protocol [RFC6325] provides optimal pair-wise data frame
forwarding

without configuration, safe forwarding even during transient
loops,

and support for multipathing of both unicast and multicast traffic in
multi-hop networks with arbitrary topology. End stations are

connected to TRILL switches with Ethernet but TRILL switches can be
interconnected with arbitrary link technology.  TRILL
accomplishes

this by using [IS-IS] (Intermediate System to Intermediate
System)

link state routing [RFC1195] [RFC6326bis] and a header that includes
a hop count.  The design supports data labeling by VLANs
(VirtualLocal Area Networks) and fine grained labels [RFCfgl] and
optimization of the distribution of multi-destination frames based on
data label and multicast groups.  Devices that implement TRILL are
called TRILL switches or RBridges (Routing Bridges).

[**]

This document provides detailed specification
of five
[for five
of the] link-local
aspects of the TRILL protocol used on broadcast links (also called LAN or
multi-access
links)[,]
and the
three of these
[and for
three]
aspects used on
point-to-point links. It includes state diagrams and implementation
details where appropriate. Alternative implementations that interoperate
on the wire are permitted.

[**]

The scope of this document is limited to the following aspects of the
TRILL protocol with applicability and

[the] section of this
document as shown:

LAN  P2P  Section
Link-Local Aspect

---  ---  -------
-----------------

X
X      3     Adjacency
formation and dissolution

X
4     DRB (Designated RBridge) election

X
X      5     MTU (Maximum
Transmission Unit) matching

X
X      6     One-hop BFD
sessions in support of adjacency

X
7     Creation and use of pseudonodes

[**]

There is no DRB (also known as
DIS or
Designated Intermediate System

DIS(Designated Intermediate
System)) election and no
pseudonode creation on links configured as point-to-point.

For other aspects of the TRILL protocol, see other documents
such as

[RFC6325], [RFC6439], [RFCclear], and [ESADI].

This
document obsoletes [RFC6327] and updates
[RFC6325].
[This sentence is the last sentence of the Abstract - should the see
appendix etc be added there and this paragraph
eliminated?]

See Appendix

A for a summary of changes from [RFC6327].

D. Eastlake, et
al
[Page 4]

INTERNET-DRAFT
TRILL: Adjacency

1.1 Content and Precedence

In case of conflict between this document and [RFC6325],
this

document prevails.

Section 2 below explains the rationale for the differences
between

the TRILL Hello protocol and the Layer 3 IS-IS Hello
protocol in

light of the environment for which the TRILL protocol is
designed.

It also describes the purposes of the TRILL Hello
protocol.

[**]

Section 3 describes the adjacency state
machine
[,]
and
[remove
"and" add
comma]
its
states
[,] and relevant
events.

[**]

Section 4 describes the Designated RBridge (DRB) election
state

machine for RBridge LAN
ports
[,]
and
[remove
"and" add
comma]
its
states
[,] and relevant
events.

Section 5 describes MTU testing and matching on a TRILL
link.

Section 6 discusses one-hop BFD session bootstrapping in
connection

with adjacency.

Section 7 discusses pseudonode creation and use on LAN
links.

Section 8 provides more details on the reception and
transmission of

TRILL Hellos.

Section 9 discusses the case of multiple ports from one
RBridge on

the same link.

1.2 Terminology and Acronyms

This document uses the acronyms defined in [RFC6325]
supplemented by

the following additional acronyms:

BFD - Bi-directional Forwarding Detection
[RFCbfd].

SNPA - Subnetwork Point of Attachment
[IS-IS].

TRILL switch - an alternative name for an
RBridge.

The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in
this

document are to be interpreted as described in
[RFC2119].

D. Eastlake, et
al
[Page 5]

INTERNET-DRAFT
TRILL: Adjacency

2. The TRILL Hello Environment and Purposes

[**]

[IS-IS] has subnetwork-independent functions and
subnetwork-dependent

functions. Currently, Layer 3 use of IS-IS supports two
types of

subnetworks: (1) point-to-point link subnetworks between
routers and

(2) general broadcast (LAN) subnetworks. Because of the
differences

between the environment of Layer 3 routers and the
environment of

TRILL RBridges, instead of the subnetwork-dependent
functions used at

Layer 3, which are specified in [IS-IS] Sections 8.2 and
8.4, the

TRILL protocol uses modified subnetwork-dependent functions
for

point-to-point subnetworks and broadcast (LAN)
subnetworks.  The

differences between the TRILL and Layer 3 environments are
described

in Sections 2.1 through 2.4, followed by a
summation
,[comma
not needed] in Section
2.5, of the purposes of the TRILL Hello protocol.

2.1 RBridge Interconnection by Ethernet

TRILL supports the interconnection of RBridges by
multi-access LAN

links such as Ethernet. Because this includes general
bridged LANs

[802.1Q], devices or services that can restrict VLAN
connectivity,

such as [802.1Q] bridges or carrier Ethernet services, can
be part of

a link between RBridges. In addition, RBridge Ethernet
ports, like

[802.1Q] ports, can be configured to restrict input/output
on a VLAN

basis.

[**]

For this reason TRILL Data and TRILL IS-IS packets are

send
[sent]on

Ethernet links in a Designated VLAN that is assumed to
provide

connectivity between all RBridges on the link.  The
Designated VLAN

is dictated for a LAN link by the elected Designated RBridge
on that

link (DRB, equivalent to the Designated Intermediate System
at Layer

3). On an RBridge Ethernet port configured as
point-to-point, TRILL

Data and IS-IS packets are sent in that port's Desired
Designated

VLAN regardless of the state of any other ports on the
link.

Connectivity on an Ethernet link configured as
point-to-point

generally depends on both ends being configured with the
same Desired

Designated VLAN. Because TRILL Data packets flow between
RBridges on

an Ethernet link only in the link's Designated VLAN,
adjacency for

routing calculations is based only on connectivity
characteristics in

that VLAN.

(Non-Ethernet links, such as PPP [RFC6361] generally do not
have any

Outer.VLAN labeling so the Designated VLAN for such links
has no

effect.)

D. Eastlake, et
al
[Page 6]

INTERNET-DRAFT
TRILL: Adjacency

2.2 Handling Native Frames

This section discusses the handling of "native"
frames as defined in

Section 1.4 of [RFC6325]. As such, this section is not
applicable to

point-to-point links between TRILL switches or any link
where all the

TRILL switch ports on the link have been configured as
"trunk ports"

by setting the end-station service disable bit for the port
(see

Section 4.9.1 of [RFC6325]).

[**]

Layer 3 data packets, such as IP packets, are already
"tamed" when

they are originated by an end station: they include a hop
count and

Layer 3 source and destination address fields.
Furthermore, for

ordinary data packets, there is no requirement to preserve
any outer

Layer 2 addressing and,
at
least
["at
least" not needed]
if the packets are unicast, they are explicitly addressed to their first
hop router.

In contrast, TRILL switches must accept, transport, and
deliver

"untamed" native frames: Native frames that lack a
hop count field

usable by TRILL and have Layer 2 MAC addresses that indicate
their

source and destination.  These Layer 2 addresses must
be preserved

for delivery to the native frame's Layer 2
destination.  One

resulting difference is that RBridge ports providing native
frame

service must receive in promiscuous MAC (Media Access
Control)

address mode, while Layer 3 router ports typically receive
in a

selective MAC address mode.

TRILL handles these requirements by having, on the link
where an end

station originates a native frame, one RBridge
"ingress" such a

locally originated native frame by adding a TRILL Header
that

includes a hop count, thus converting it to a TRILL Data
packet.

This augmented packet is then routed to one RBridge on the
link

having the destination end station for the frame (or one
RBridge on

each such link if it is a multi-destination frame).
Such final

RBridges perform an "egress" function, removing
the TRILL Header and

delivering the original frame to its destination(s).
(For the

purposes of TRILL, a Layer 3 router is an end
station.)

Care must be taken to avoid a loop that would involve
egressing a

native frame and then re-ingressing it because, while it is
in native

form, it would not be protected by a hop count and could
loop

forever.  Such a loop could even, for multi-destination
frames,

involve multiplication of the number of frames each time
around and

would likely saturate all links involved within
milliseconds.  For

TRILL, safety against such loops for a link is more
important than

transient loss of data connectivity on that link.

The primary TRILL defense mechanism against such loops,
which is

mandatory, is to assure that, as far as practically
possible, there

is only a single RBridge that is in charge of ingressing
and

egressing native frames from and to a link where TRILL is
offering

D. Eastlake, et
al
[Page 7]

INTERNET-DRAFT
TRILL: Adjacency

end station service.  This is the Designated RBridge
that is elected

using TRILL LAN Hellos as further described in Sections 2.5
and 4

below. See also [RFC6439].

2.3 Zero or Minimal Configuration

[**]

TRILL provides connectivity and least cost paths with
zero

configuration. For additional services, it strives to
require only

minimal configuration; however,
services
that require configuration

when offered by [802.1Q] bridges, such as non-default VLAN
or

priority, will require
configuration.
[??
saying
the services require configuration when offered then saying they require
configuration seems redundant to me. I may be missing a point but if not
the following works better
services
that are offered by [802.1Q] bridges, such as non-default VLAN or
priority, will require
configuration.]
This differs from Layer 3 routing where routers typically need to be
configured as to the

subnetworks connected to each port, etc., to provide
service.

2.4 MTU Robustness

[**]

TRILL IS-IS needs to be robust

against
[??
on] links with
reasonably

restricted MTUs, including links that accommodate only the
classic

Ethernet frame size, despite the addition of reasonable
headers such

as VLAN tags.  Such robustness is particularly required
for TRILL

Hellos
so
as
["so
as" not needed] to
assure correct adjacency and the election of a unique DRB on LAN
links.

NOTE:
When the following
word starts with a vowel, you will use
'an' else you use an
'a'.

[**]

TRILL will also be used inside data centers where it is
common for

all or most of the links and switches to support frames
substantially

larger than the classic Ethernet limit.  For example,
they may have

an

[a]
MTU adequate to comfortably
handle Fiber Channel over Ethernet

frames, for which T11 recommends a 2,500-byte MTU [FCoE], or
even 9K

byte jumbo frames.  It would be beneficial for
an

[a]
TRILL campus with such a large
MTU to be able to safely make use of it.

These needs are met by a mandatory limit on the size of
TRILL Hellos

and by the optional use of MTU testing as described
below.

2.5 Purposes of the TRILL Hello Protocol

There are three purposes for the TRILL Hello protocol. They
are

listed below along with a reference to the section of this
document

in which each is discussed:

a) To determine which RBridge neighbors have acceptable
connectivity

to be reported as part of the topology
(Section 3)

[**]

b) To elect a unique Designated RBridge on

[the] broadcast (LAN)
link

D. Eastlake, et
al
[Page 8]

INTERNET-DRAFT
TRILL: Adjacency

(Section 4)

c) To determine the MTU with which it is possible to
safely

communicate with each RBridge neighbor
(Section 5)

In Layer 3 IS-IS, all three of these functions are combined.
Hellos

may be padded to the maximum length (see [RFC3719], Section
6) so

that a router neighbor is not even discovered if it is
impossible to

communicate with it using maximum-sized Layer 3 IS-IS
packets.  Also,

even if Hellos from a neighbor R2 are received by R1, if
connectivity

to R2 is not 2-way (i.e., R2 does not list R1 in R2's
Hello), then R1

does not consider R2 as a Designated Intermediate System
(Designated

Router) candidate.  Because of this logic, it is
possible at Layer 3

for multiple Designated Routers to be elected on a LAN, with
each

representing the LAN as a pseudonode.  It appears to
the topology as

if the LAN is now two or more separate LANs.  Although
this is

surprising, this does not cause problems for Layer
3.

In contrast, this behavior is not acceptable for TRILL,
since in

TRILL it is important that all RBridges on a link know about
each

other, and on broadcast (LAN) links that they choose a
single RBridge

to be the DRB to control the native frame ingress and
egress.

Otherwise, multiple RBridges might ingress/egress the same
native

frame, forming loops that are not protected by the hop count
in the

TRILL header as discussed above.

The TRILL Hello protocol is best understood by focusing
separately on

each of these three functions listed above which we do in
Sections 3,

4, and 5.

One other issue with TRILL LAN Hellos is to ensure that
subsets of

the information can appear in any single message, and be
processable,

in the spirit of IS-IS Link State PDUs (LSPs) and Complete
Sequence

Number PDUs (CSNPs). LAN TRILL Hello packets, even though
they are

not padded, can become very large.  An example where
this might be

the case is when some sort of backbone technology
interconnects

hundreds of TRILL sites over what would appear to TRILL to
be a giant

Ethernet, where the RBridges connected to that cloud will
perceive

that backbone to be a single link with hundreds of
neighbors.  Thus,

the TRILL LAN Hello uses a different Neighbor TLV
[RFC6326bis] that

lists neighbors seen for a range of MAC (SNPA)
addresses.

D. Eastlake, et
al
[Page 9]

INTERNET-DRAFT
TRILL: Adjacency

3. Adjacency State Machinery

[**]

Each RBridge port has associated with it a port state, as
discussed

in Section 4, and a table of zero or more adjacencies (if
the port is

configured as point-to-point, zero or one) as discussed in
this

section. The states such adjacencies can have, the events
that cause

adjacency state changes, the actions associated with those
state

changes,
and a
state table and diagram
[a state
table, and a diagram] are
given below.

3.1 TRILL Hellos, Ports, and VLANs

[**]

The determination of adjacencies on links is made using
TRILL Hellos

(see

also

["also" not
needed] Section 8), an
optional MTU test (see Section 5), and optionally BFD (see Section 6)
and/or other connectivity tests.  If the MAC (SNPA) address of more
than one RBridge port on a broadcast link are the same, all but one of
such ports are put in the Suspended state (see Section 4) and do not
participate in the link except to monitor whether they should stay
suspended. If the two ports on a

point-to-point link have MAC (SNPA) addresses it does not
affect

TRILL operation if they are the same. (PPP ports, for
example, do not

have MAC addresses [RFC6361].)

The following items MUST be the same for all TRILL Hellos
issued by

an RBridge on a particular Ethernet port regardless of the
VLAN in

which the Hello is sent:

-  Source MAC address,

-  Priority to be DRB,

-  Desired Designated VLAN,

-  Port ID, and,

- if included, BFD Enabled TLV [RFC6213]
and PORT-TRILL-VER sub-

TLV
[RFC6326bis].

Of course, the priority, Desired Designated VLAN, and
possibly the

inclusion or value of the PORT-TRILL-VER sub-TLV, and/or BFD
Enabled

TLV can change on occasion, but then the new value(s) must
similarly

be used in all TRILL Hellos on the LAN port, regardless of
VLAN.

[**]

On

braodcast

[broadcast]
links:

Because bridges acting as glue on an
Ethernet broadcast link might

be configured in such a way that some
VLANs are partitioned, it is

necessary for RBridges to transmit Hellos
on Ethernet links with

multiple VLAN tags.  The conceptually
simplest solution may have

been to have RBridges transmit up to 4,094
times as many Hellos,

one with each legal VLAN ID enabled at
each port, but this would

obviously have deleterious performance
implications.  So, the

TRILL protocol specifies that if RB1 knows
it is not the DRB, it

D. Eastlake, et
al
[Page 10]

INTERNET-DRAFT
TRILL: Adjacency

[**]

transmits its Hellos on only a limited set
of VLANs. Only
an
[a]

RBridge that believes itself to be the DRB
on a broadcast Ethernet

link "sprays" its TRILL Hellos
on all of its enabled VLANs at the

port. And in both cases,
an
[a]
RBridge can be configured to
send

Hellos on only a subset of those
VLANs.  The details are given in

[RFC6325], Section 4.4.3.

On point-to-point links:

[**]

If the link technology is VLAN sensitive,
such as Ethernet,
an
[a]

RBridge sends TRILL Hellos only in the
Desired Designated VLAN for

which it is configured.

3.2 Adjacency Table Entries and States

[**]

Each adjacency on broadcast links and the one possible
adjacency on

each point-to-point link is in one of four states.
An
[a]
RBridge

participates in LSP synchronization at a port as long as it
has one

or more adjacencies out that port that are in the 2-way or
Report

state.

Down:

This is a virtual state
for convenience in creating state

diagrams and
tables.  It indicates that the adjacency is non-

existent, and there is
no entry in the adjacency table for it.

Detect:

A neighbor RBridge has
been detected through receipt of a TRILL

Hello but either 2-way
connectivity has not been confirmed or

the detection was on an
Ethernet link in a VLAN other than the

Designated
VLAN.

2-Way:

2-way connectivity to
the neighbor has been found and, if the

link is Ethernet, it was
found on the Designated VLAN, but some

enabled test, such as
MTU meeting the minimum campus

requirement or BFD
confirming connectivity, has not yet

succeeded.

Report:[**]

There is 2-way
connectivity to the neighbor (on the Designated

VLAN if an Ethernet
link) and all enabled tests have succeeded

including, if enabled,
MTU and/or BFD testing.  This state will

cause adjacency to be
reported in
an
[a]
LSP (with appropriate

provision for a
pseudonode, if any, as described in Section 7).

For an adjacency in any of the three non-Down states
(Detect, 2-Way,

or Report), there will be an adjacency table entry.
That entry will

D. Eastlake, et
al
[Page 11]

INTERNET-DRAFT
TRILL: Adjacency

give the state of the adjacency and will also include the
information

listed below.

[**]

o  The address, if any, of the
neighbor
[,]
and

["and" not

needed]the Port
ID[,]
and the System ID in the
received Hellos.

Together, these three quantities uniquely identify the
adjacency

on a broadcast link.

[**]

o  For a point-to-point adjacency,
[there
is] a single Hello

holding timer.

For a broadcast LAN adjacency,
[there
are] exactly two
Hello

holding timers: a Designated VLAN holding timer and a
non-

Designated VLAN holding timer. Each timer

consisting

[consists]

of a
16-bit unsigned integer number of seconds.

[**]

o  If the adjacency is on a
broadcast link, the 7-bit unsigned

priority of the neighbor
to
be
[this
sentence doesn't make sense to
me.
Do you
mean "that is" rather than "to
be"??] the
DRB.

o  The 5 bytes of data from the
PORT-TRILL-VER received in the

most recent TRILL Hello
from the neighbor RBridge.

o  The VLAN that the neighbor RBridge
wants to be the Designated

VLAN on the link, called
the Desired Designated VLAN.

o  For an adjacency table at
an

[a]
RBridge that supports BFD,
a

flag indicating whether the last received TRILL
Hello from the

neighbor RBridge contained a BFD Enabled TLV (see
Section 6).

3.3 Adjacency and Hello Events

The following events can change the state of an
adjacency:

[**]

A0.
Receive

[Receives] a TRILL Hello
for a broadcast LAN adjacency whose source MAC address (SNPA) is equal to
that of the port on
which it is received.  This is a special event that cannot occur on
a port configured as point-to-point and is handled as described
immediately after this list of events.  It does not appear in the
state transition table or diagram.

[**]

A1.
Receive

[Receives] a TRILL Hello
(other than an A0 event) such that:

-  If
received on an Ethernet port, it was received in the

Designated VLAN.

-  If
received for a broadcast LAN adjacency, it contains a

TRILL Neighbor TLV that explicitly lists the receiving

port's (SNPA) address.

-  If
received for a point-to-point adjacency, it contains a

Three-Way Handshake TLV with the receiver's System ID and

Extended Circuit ID.

A2. Event A2 is not possible for a port
configured as point-to-

D. Eastlake, et
al
[Page 12]

INTERNET-DRAFT
TRILL: Adjacency

[**] point.
Receive

[Receives] a TRILL Hello
(other than an A0 event) such that either

-  The port is Ethernet and the Hello was not on the
Designated VLAN

(any TRILL Neighbor TLV in such a Hello is
ignored), or

-  The Hello does not contain a TRILL Neighbor TLV covering an
address

range that includes the receiver's (SNPA)
address.

[**]

A3. Receive

[Receives] a TRILL Hello
(other than an A0 event) such that:

-  If received on an Ethernet port, it was
received in the

Designated VLAN.

-  If received for a broadcast LAN adjacency, it
contains one or more

TRILL Neighbor TLVs covering an
address range that includes the

receiver's (SNPA) address and none
of which lists the receiver.

-  If received for a point-to-point adjacency, it
contains a Three-Way

Handshake TLV with either the System ID or
Extended Circuit ID or

both not equal to that of the
receiver.

[**]

A4. Either (1) the Hello holding timer expires on a point-to-point

adjacency or (2) one or both Hello holding timers

expires
[expire] on

a broadcast LAN adjacency resulting in them both being
in the expired

state for that adjacency.

A5. For a broadcast LAN adjacency, the Designated VLAN Hello holding

timer expires, but the non-Designated VLAN Hello
holding timer still

has time left until it expires. This event cannot
occur for a point-

to-point adjacency.

A6. MTU if enabled, BFD if enabled, and all other enabled connectivity

tests successful.

A7. MTU if enabled, BFD if enabled, and all other enabled
connectivity

tests were successful but one or more now
fail.

A8. The RBridge port goes operationally down.

[**]

For the
special A0 event, the Hello is examined to determine if it is

higher priority to be the DRB than the port on which it is received as
described in Section 4.2.1.

[
if I've understood this then:
For the
special A0 event, the Hello is examined to determine if it has a higher
priority than the port on which it was received such that the sending
port should be the DBR as described in Section
4.2.1.] If the Hello is
of lower priority than the receiving port, it is discarded with no
further action.  If it is of higher priority than the receiving
port, then any adjacencies for the receiving port are discarded
(transitioned to the Down state), and the port is suspended as described
in Section 4.2.

[**]

The receipt of a TRILL Hello that is not an event A0, causes the
following actions (except where the Hello would create a new adjacency
table entry, the table is full,
and

[or] the Hello is too low
priority to displace an existing entry as described in Section 3.6).

D. Eastlake, et
al
[Page 13]

INTERNET-DRAFT
TRILL: Adjacency

The Designated VLAN referred to is the Designated VLAN
dictated by

the DRB determined without taking the received TRILL LAN
Hello into

account (see Section 4) for a broadcast LAN and the local
Desired

Designated VLAN for a port configured as
point-to-point.

o  If the receipt of a Hello creates
a new adjacency table entry,

the neighbor RBridge MAC
(SNPA) address (if any), Port ID, and

System ID are set from
the Hello.

o  For a point-to-point adjacency,
the Hello holding timer is set

from the Holding Time
field of the Hello. For a broadcast link

adjacency, the
appropriate Hello holding timer for that

adjacency, depending on
whether or not the Hello was received

in the Designated VLAN,
is set to the Holding Time field of the

Hello and if the receipt
of the LAN Hello is creating a new

adjacency table entry,
the other timer is set to expired.

o  For a broadcast link adjacency,
the priority of the neighbor

RBridge to be the DRB is
set to the priority field of the LAN

Hello.

o  For a broadcast link adjacency,
the VLAN that the neighbor

RBridge wants to be the
Designated VLAN on the link is set from

the Hello.

o  The five bytes of PORT-TRILL-VER
data are set from that sub-TLV

in the Hello or set to
zero if that sub-TLV does not occur in

the Hello.

o  For a broadcast link, if the
creation of a new adjacency table

entry or the priority
update above changes the results of the

DRB election on the
link, the appropriate RBridge port event

(D2 or D3) occurs, after
the above actions, as described in

Section 4.2.

o  For a broadcast link adjacency, if
there is no change in the

DRB, but the neighbor
Hello is from the DRB and has a changed

Designated VLAN from the
previous Hello received from the DRB,

the result is a change
in Designated VLAN for the link as

specified in Section
4.2.3.

An event A4 resulting in the adjacency transitioning to the
Down

state may also result in an event D3 as described in Section
4.2.

Concerning events A6 and A7, if none of MTU, BFD, or other
testing is

enabled, A6 is considered to occur immediately upon the
adjacency

entering the 2-Way state, and A7 cannot occur.

See further TRILL Hello receipt details in Section
7.

D. Eastlake, et
al
[Page 14]

INTERNET-DRAFT
TRILL: Adjacency

3.4 Adjacency State Diagram and Table

The table below shows the transitions between the states
defined

above based on the events defined above:

| Event |  Down  | Detect | 2-Way  | Report |

+-------+--------+--------+--------+--------+

|  A1   | 2-Way  | 2-Way  | 2-Way  | Report
|

|  A2   | Detect | Detect | 2-Way  | Report |

|  A3   | Detect | Detect | Detect | Detect |

|  A4   |  N/A   | Down   |
Down   | Down   |

|  A5   |  N/A   | Detect | Detect | Detect
|

|  A6   |  N/A   |  N/A   |
Report | Report |

|  A7   |  N/A   |  N/A   |
2-Way  | 2-Way  |

|  A8   | Down   | Down   |
Down   | Down   |

N/A indicates that the event to the left is Not Applicable
in the

state at the top of the column.  These events affect
only a single

adjacency.  The special A0 event transitions all
adjacencies to Down,

as explained immediately after the list of adjacency events
above.

The diagram below presents the same information as that in
the state

table:

D. Eastlake, et
al
[Page 15]

INTERNET-DRAFT
TRILL: Adjacency

+---------------+

|     Down
|<--------+

+---------------+         |

|     |  ^
|           |

A2,A3|     |A8|
|A1         |

|     +--+
|           |

|
+-----------|---+

V
|   |

+----------------+ A4,A8  |   |

+----->|      Detect
|------->|   |

|
+----------------+
|   |

|        |
|
^          |
|

|      A1|  |A2,A3,A5
|          |
|

|        |
+---------+
|   |

|
|
|   |

|
|
+------------|---+

|
|
|
|

|
V
V
|

|A3,A5 +----------------+ A4,A8  |

|<-----|     2-Way
|------->|

|
+----------------+        |

|       |   ^
|
^         |

|     A6|   |
|A1,A2,A7|         |

|       |   |
+--------+         |

|       |
|
|

|       |
|A7
|

|       V
|
|

|A3,A5 +-------------+ A4,A8     |

|<-----|   Report    |---------->|

+-------------+

|         ^

|A1,A2,A6 |

+---------+

3.5 Multiple Parallel Links

[**]

There can be multiple parallel adjacencies between neighbor
RBridges

that are visible to TRILL. (Multiple low-level links that
have been

bonded together by technologies such as link aggregation
[802.1AX]

appear to TRILL as a single link over which only a single
TRILL

adjacency

could

[can] be
established.)

Any such links that have pseudonodes (see Section 7)
are

distinguished in the topology; such adjacencies, if they are
in the

Report
state,
appear in LSPs as per
Section 7.  However, there can be

multiple parallel adjacencies without pseudonodes because
they are

point-to-point adjacencies or LAN adjacencies for which a
pseudonode

is not being created. Such parallel, non-pseudonode
adjacencies in

D. Eastlake, et
al
[Page 16]

INTERNET-DRAFT
TRILL: Adjacency

the Report state appear in LSPs as a single adjacency. The
cost of

such an adjacency MAY be adjusted downwards to account for
the

parallel paths.  Multipathing across such parallel
connections can be

freely done for unicast TRILL Data traffic on a per-flow
basis but is

restricted for multi-destination traffic, as described in
Section

4.5.2 (point 3) and Appendix C of [RFC6325].

3.6 Insufficient Space in Adjacency Table

If the receipt of a TRILL Hello would create a new adjacency
table

entry (that is, would transition an adjacency out of the
Down state),

there may be no space for the new entry.  It is
RECOMMENDED, for

ports configured as point-to-point and which can thus only
have zero

or one adjacency not in the Down state, to
reserved

[reserve]
space

for one adjacency so that this condition cannot
occur.

When there is adjacency table space exhaustion, the DRB
election

priority (see Section 4.2.1) of the new entry that would be
created

is compared with that priority for the existing entries. If
the new

entry is higher priority than the lowest priority existing
entry, it

replaces the lowest priority existing entry, which is
transitioned to

the Down state.

D. Eastlake, et
al
[Page 17]

INTERNET-DRAFT
TRILL: Adjacency

4. LAN Ports and DRB State

This section specifies the DRB election process in TRILL at
a

broadcast (LAN) link port. Since there is no such election
when a

port is configured as point-to-point, this section does not
apply in

that case.

[**]

The information at
an
[a]
RBridge associated with
each of its broadcast LAN ports includes the following:

o  Enablement bit, which defaults to
enabled.

o  The five bytes of PORT-TRILL-VER
sub-TLV data used in TRILL

Hellos sent on the
port.

o  SNPA address (commonly a 48-bit
MAC address) of the port.

o  Port ID, used in TRILL Hellos sent
on the port.

o  The Holding Time, used in TRILL
Hellos sent on the port.

o  The Priority to be the DRB, used
in TRILL LAN Hellos sent on

the port.

o  If the port supports BFD, a BFD
enabled flag that controls

whether or not a BFD
Enabled TLV is included in TRILL Hellos

sent on the
port.

o  The DRB state of the port,
determined as specified below.

o  A 16-bit unsigned Suspension
timer, measured in seconds.

o  The desired Designated VLAN. The
VLAN this RBridge wants to be

the Designated VLAN for
the link out this port, used in TRILL

Hellos sent on the port
if the link is Ethernet.

o  A table of zero or more
adjacencies (see Section 3).

4.1 Port Table Entries and DRB Election State

The TRILL equivalent of the DIS (Designated Intermediate
System) on a

broadcast link is the DRB or Designated RBridge.  The
DRB election

state machinery is described below.

Each RBridge port that is not configured as point-to-point
is in one

of the following four DRB states:

D. Eastlake, et
al
[Page 18]

INTERNET-DRAFT
TRILL: Adjacency

Down:

The port is
operationally down.  It might be administratively

disabled or down at the
link layer.  In this state, there will

be no adjacencies for
the port, and no TRILL Hellos or other

TRILL IS-IS PDUs or
TRILL Data packets are accepted or

transmitted.

Suspended:

Operation of the port is
suspended because there is a higher

priority port on the
link with the same MAC (SNPA) address.

This is the same as the
down state with the exception that

TRILL Hellos are
accepted for the sole purpose of determining

whether to change the
value of the Suspension timer for the

port as described
below.

DRB:

The port is the DRB and
can receive and transmit TRILL Data

packets.

Not DRB:

The port is deferring to
another port on the link, which it

believes is the DRB, but
can still receive and transmit TRILL

Data packets.

4.2 DRB Election Events

The following events can change the DRB state of a port.
Note that

this is only applicable to broadcast links. There is no DRB
state or

election at a port configured to be point-to-point.

D1. Expiration of the suspension timer
while the port is in the

Suspended state or
the enablement of the port.

D2. The adjacency table for the port
changes and there are now

entries for one or
more other RBridge ports on the link that

appear to be
higher priority to be the DRB than the local

port.

D3. The port is not Down or Suspended, and
the adjacency table for

the port changes,
so there are now no entries for other

RBridge ports on
the link that appear to be higher priority to

be the DRB than
the local port.

D4. Receipt of a TRILL LAN Hello with the
same MAC address (SNPA)

as the receiving
port and higher priority to be the DRB as

described for
event A0.

D5. The port becomes operationally
down.

D. Eastlake, et
al
[Page 19]

INTERNET-DRAFT
TRILL: Adjacency

Event D1 is considered to occur on RBridge boot if the port
is

administratively and link-layer enabled.

Event D4 causes the port to enter the Suspended state and
all

adjacencies for the port to be discarded (transitioned to
the Down

state).  If the port was in some state other than
Suspended, the

suspension timer is set to the Holding Time in the Hello
that causes

event D4.  If it was in the Suspended state, the
suspension timer is

set to the maximum of its current value and the Holding Time
in the

Hello that causes event D4.

4.2.1 DRB Election Details

Events D2 and D3 constitute losing and winning the DRB
election at

the port, respectively.

The candidates for election are the local RBridge and all
RBridges

with which there is an adjacency on the port in an adjacency
state

other than Down state.  The winner is the RBridge with
highest

priority to be the DRB, as determined from the 7-bit
priority field

in that RBridge's Hellos received and the local port's
priority to be

the DRB field, with MAC (SNPA) address as a tiebreaker, Port
ID as a

secondary tiebreaker, and System ID as a tertiary
tiebreaker.  These

fields are compared as unsigned integers with the larger
magnitude

being considered higher priority.

Resort to the secondary and tertiary tiebreakers should only
be

necessary in rare circumstances when multiple ports have the
same

priority and MAC (SNPA) address and some of them are not
yet

suspended.  For example, RB1, that has low priority to
be the DRB on

the link, could receive Hellos from two other ports on the
link that

have the same MAC address as each other and are higher
priority to be

the DRB.  One of these two ports with the same MAC
address will be

suspended, cease sending Hellos, and the Hello from it
received by

RB1 will eventually time out.  But, in the meantime,
RB1 can use the

tiebreakers to determine which port is the DRB and thus
which port's

Hello to believe for such purposes as setting the Designated
VLAN on

the link.

4.2.2 Change in DRB

Events D2 and D3 result from a change in the apparent DRB on
the

link.  Unnecessary DRB changes should be avoided,
especially on links

offering native frame service, as a DRB change will
generally cause a

transient interruption to native frame service.

D. Eastlake, et
al
[Page 20]

INTERNET-DRAFT
TRILL: Adjacency

If a change in the DRB on the link changes the Designated
VLAN on an

Ethernet link, the actions specified in Section 4.2.3 are
taken.

If an RBridge changes in either direction between being the
DRB and

not being the DRB at a port, this will generally change the
VLANs on

which Hellos are sent by that RBridge on that port as
specified in

Section 4.4.3 of [RFC6325].

4.2.3 Change in Designated VLAN

Unnecessary changes in the Designated VLAN on an Ethernet
link should

be avoided because a change in the Designated VLAN can cause
a

transient interruption to adjacency and thus to TRILL Data
forwarding

on the link.  When practical, all RBridge ports on a
link should be

configured with the same Desired Designated VLAN so that, in
case the

winner of the DRB election changes, for any reason, the
Designated

VLAN will remain the same.

If an RBridge detects a change in Designated VLAN on an
Ethernet

link, then, for all adjacency table entries for a port to
that link,

the RBridge takes the following steps in the order
given.

o  The non-Designated VLAN Hello
Holding timer is set to the

maximum of its time to
expiration and the current time to

expiration of the
Designated VLAN Hello Holding timer.

o  The Designated VLAN Hello Holding
timer is then set to expired

(if necessary), and an
event A5 occurs for the adjacency (see

Section 3.3).

If the Designated VLAN for a link changes, this will
generally change

the VLANs on which Hellos are sent by an RBridge port on
that link as

specified in Section 4.4.3 of [RFC6325].

4.3 State Table and Diagram

The table below shows the transitions between the DRB states
defined

above based on the events defined above:

| Event | Down   | Suspend |  DRB    | Not
DRB |

+-------+--------+---------+---------+---------+

|  D1   | DRB    |
DRB     |  N/A    |
N/A    |

|  D2   |  N/A   |
N/A    | Not DRB | Not DRB |

|  D3   |  N/A   |
N/A    | DRB     |
DRB     |

|  D4   |  N/A   | Suspend | Suspend |
Suspend |

|  D5   | Down   | Down    |
Down    | Down    |

D. Eastlake, et
al
[Page 21]

INTERNET-DRAFT
TRILL: Adjacency

N/A indicates that the event to the left is Not Applicable
in the

state at the top of the column.

The diagram below presents the same information as in the
state

table:

+-------------+

|  Down
|<--------------+

+-+---+-------+
^         |

|   |
^
|         |

D1|   |D5 |
|         |

|   +---+
|D5       |

|
|         |

|
+--------+----+    |

|        |  Suspended
|<---|---+

|
+-+-----+-----+    |   |

|        D1|  ^
|   ^      |   |

|          |  |
|D4 |      |   |

|          |  |
+---+      |   |

|          |
|
|   |

|          |
|D4
|   |

V          V
|
|   |

+---------------+-+ D5
|   |

|
DRB    |---------->|   |

+--------+--+-----+
|   |

^    |  |
^
|   |

|  D2|
|D3|
|   |

|    |
+--+
|   |

|    |
D4         |   |

|D3  |  +-----------------|---+

|    V
|
|

+----+-------+-+
D5
|

|   Not DRB    |-------------->|

+----+---------+

|    ^

|D2  |

+----+

D. Eastlake, et
al
[Page 22]

INTERNET-DRAFT
TRILL: Adjacency

5. MTU Matching

[**]

The purpose of MTU testing is to ensure that the links used
in the

campus topology can pass TRILL IS-IS packets, particularly
LSP PDUs,

at the TRILL campus MTU. The LSP PDUs generated at a TRILL
switch

could, as part of the flooding process, be sent over any
adjacency in

the campus. To assure correct operation of IS-IS, an LSP PDU
must be

able to reach every RBridge in the IS-IS reachable campus,
which

might be impossible if the PDU exceeded the MTU of
a

[an] adjacency

that was part of the campus topology.

[**]

An
[A]
RBridge, RB1, determines the
desired campus link MTU by

calculating the minimum of its originatingL1LSPBufferSize
and the

originatingL1LSPBufferSize of other RBridges in the campus,
as

advertised in the link state database or received in TRILL
Hellos,

but not less than 1,470 bytes.  Although
originatingL1LSPBufferSize

in Layer 3 [IS-IS] is limited to the range 512 to 1,492
bytes

inclusive, in TRILL it is limited to the range 1,470 to
65,535 bytes

inclusive. (See Section 5 of [RFCclear].)

[**]

Although MTU testing is optional, it is mandatory for an
RBridge to

respond to an MTU-probe PDU with an MTU-ack PDU
[RFC6325]

[RFC6326bis].  Use of multicast or unicast for
MTU-probe and MTU-ack

is an implementation choice.  However, the burden on
the link is

generally minimized by multicasting MTU-probes when a
response from

all other RBridges on the link is desired, such as when
initializing

or
re-
confirming

[re-configuring]
MTU
,
[.]

unicasting
[The
burden on the link is also minimized by
unicasting] MTU-probes
when a response from a single RBridge is desired, such as one that has
just been detected on the link, and unicasting all MTU-ack
packets.

RB1 can test the MTU size to RB2 as described in Section
4.3.2 of

[RFC6325].  For this purpose, MTU testing is only done
in the

Designated VLAN.  An adjacency that fails the MTU test
at the campus

MTU will not enter the Report state or, if the adjacency is
in that

state, it leaves that state.  Thus, an adjacency
failing the MTU test

at the campus minimum MTU will not be reported by the
RBridge

performing the test.  Since inclusion in least-cost
route computation

requires the adjacency to be reported by both ends, as long
as the

RBridge at either end of the adjacency notices the MTU
failure, it

will not be so used.

If it tests MTU, RB1 reports the largest size for which the
MTU test

succeeds or a flag indicating that it fails at the campus
MTU.  This

report always appears with the neighbor in RB1's TRILL
Neighbor TLV.

RB1 MAY also report this with the adjacency in an
Extended

Reachability TLV in RB1's LSP.  RB1 MAY choose to test
MTU sizes

greater than the desired campus MTU as well as the desired
campus

MTU.

Most types of TRILL IS-IS packets, such as LSPs, can make
use of the

D. Eastlake, et
al
[Page 23]

INTERNET-DRAFT
TRILL: Adjacency

campus MTU.  The exceptions are TRILL Hellos, which
must be kept

small for loop safety, and the MTU PDUs, whose size must be
adjusted

appropriately for the tests being performed.

D. Eastlake, et
al
[Page 24]

INTERNET-DRAFT
TRILL: Adjacency

6. BFD Enabled and BFD Session Bootstrap

When the adjacency between RBridges reaches the 2-Way state,
TRILL

Hellos will already have been exchanged. If an RBridge
supports BFD

[RFCbfd] it will have learned whether the other RBridge has
BFD

enabled by whether or not a BFD Enabled TLV was included in
its

Hellos. In addition, TRILL Hellos include a nickname of the
sending

RBridge [RFC6326bis] so that information will be available
to the

receiving RBridge.

The BFD Enabled TLVs in TRILL Hellos will look like the
following:

+-+-+-+-+-+-+-+-+

|
Type=148
|
(1 bytes)

+-+-+-+-+-+-+-+-+

|
Length=3
|
(1 bytes)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| RESV
|
MTID=0        |   (2
bytes)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|
NLPID=0xC0
|
(1 bytes)

+-+-+-+-+-+-+-+-+

Type = 148 for BFD
Enabled.

Length will be 3 times
the number of topology and protocol

entries in the
TLV.

MTID is a topology ID
which will be zero unless multi-topology

is being
supported.

NLPID is a Network Layer
Protocol ID and will be 0xC0 for TRILL

[RFC6328] but additional
topology and protocol entries could

conceivably list other
NLPIDs.

[**]

An

[A]
RBridge port initiates a
one-hop BFD session with another RBridge if the following conditions are
met: (1) it has BFD enabled, (2) it has an adjacency to another RBridge
in the 2-way or Report state, and

(3) the Hellos it receives indicate that the other RBridge also has BFD
endabled

[enabled]
. Either BFD was enabled
on both RBridge ports when the adjacency changed to the 2-way or Report
state or the adjacency was already in 2-way or Report state and BFD was
enabled on one RBridge port when BFD had been enabled on the other or BFD
was simultaneously   enabled on both RBridge ports.

[**]

In such a BFD session, BFD is encapsulated as
specfied

[specified] in [RFCbfd].
The egress nickname to be used will have been learned from received
Hellos. On a point-to-point link, the Any-RBridge nickname [RFCclear] can
also be used as egress since support of that nickname is required by
support of RBridge Channel [RFCchannel] which is in turn required for
support of BFD over TRILL.  In the rare case where, on a

D. Eastlake, et
al
[Page 25]

INTERNET-DRAFT
TRILL: Adjacency

broadcast link, an adjacency to/from a formerly isolated
RBridge

comes up to the 2-way or Report state and there is transient
nickname

duplication, LSP synchronization on the link will also start
on

achieving the 2-way or Report state and BFD bootstrapping
can be

delayed until the duplicate nicknames are resolved.

If a one-hop BFD session is initiated when the adjacency is
in the

2-way state, the adjacency MUST NOT advance to the Report
state until

BFD and any other enabled connectivity test (including MTU
if

enabled) have succeeded, as specified in Section 3.

If a one-hop BFD session is initiated when the adjacency is
in the

Report state, due to enablement at the RBridges, then, to
minimize

unnecessary topology changes, the adjacency MUST remain in
the Report

state unless and until the BFD session (or some other
enabled

connectivity test) reports failure.

D. Eastlake, et
al
[Page 26]

INTERNET-DRAFT
TRILL: Adjacency

7. Pseudonodes

[**]

This section only applies to broadcast links as there is no
DRB and

[there] cannot be a
pseudonode for a link configured as point-to-point. The Designated
RBridge (DRB), determined as described above, controls whether a
pseudonode will be used on a link.

If the DRB sets the bypass pseudonode bit in its TRILL LAN
Hellos,

the RBridges on the link (including the DRB) just directly
report all

their adjacencies on the LAN that are in the Report
state.  If the

DRB does not set the bypass pseudonode bit in its TRILL
Hellos, then

(1) the DRB reports in its LSP its adjacency to the
pseudonode, (2)

the DRB sends LSPs on behalf of the pseudonode in which it
reports

adjacency to all other RBridges on the link where it sees
that

adjacency in the Report state, and (3) all other RBridges on
the link

report their adjacency to the pseudonode if they see their
adjacency

to the DRB as being in the Report state and do not report
any other

adjacencies on the link.  Setting the bypass pseudonode
bit has no

effect on how LSPs are flooded on a link.  It only
affects what LSPs

are generated.

It is anticipated that many links between RBridges will
actually be

point-to-point, in which case using a pseudonode merely adds
to the

complexity.  For example, if RB1 and RB2 are the only
RBridges on the

link, and RB1 is DRB, then if RB1 creates a pseudonode that
is used,

there are 3 LSPs: for, say, RB1.25 (the pseudonode), RB1,
and RB2,

where RB1.25 reports connectivity to RB1 and RB2, and RB1
and RB2

each just say they are connected to RB1.25.  Whereas if
DRB RB1 sets

the bypass pseudonode bit in its Hellos, then there will be
only 2

LSPs: RB1 and RB2 each reporting connectivity to each
other.

A DRB SHOULD set the bypass pseudonode bit in its Hellos if
it has

not seen at least two simultaneous adjacencies in the Report
state

since it last rebooted or was reset by network
management.

D. Eastlake, et
al
[Page 27]

INTERNET-DRAFT
TRILL: Adjacency

8. More TRILL Hello Details

This section provides further details on the receipt,
transmission,

and content of TRILL Hellos. Unless otherwise stated, it
applies to

both LAN and point-to-point Hellos.

TRILL Hellos, like all TRILL IS-IS packets, are
primarily

distinguished from Layer 3 IS-IS packets on Ethernet by
being sent to

the All-IS-IS-RBridges multicast address
(01-80-C2-00-00-41).  TRILL

IS-IS packets also have the L2-IS-IS Ethertype (0x22F4) and
are

Ethertype encoded.

Although future extensions to TRILL may include use of Level
2 IS-IS,

[RFC6325] specifies TRILL using a single Level 1 Area using
the fixed

Area Address zero (see Section 4.2 of
[RFC6326bis]).

IS-IS Layer 3 routers are frequently connected to other
Layer 3

routers that are part of a different routing domain.
In that case,

the externalDomain flag (see [IS-IS]) is normally set for
the port

through which such a connection is made.  The setting
of this flag to

"true" causes no IS-IS PDUs to be sent out the
port and any IS-IS

PDUs received to be discarded, including Hellos.
RBridges operate in

a different environment where all neighbor RBridges merge
into a

single campus.  For loop safety, RBridges do not
implement the

externalDomain flag or implement it with the fixed value
"false".

They send and can receive TRILL Hellos on every port that is
not

disabled.

8.1 Contents of TRILL Hellos

The table below lists mandatory (M) and optional (O) content
TLVs for

TRILL Hellos that are particularly relevant to this
document,

distinguishing between TRILL LAN Hellos and TRILL P2P
Hellos. A "-"

indicates that an occurrence would be ignored. There are
additional

TLVs and sub-TLVs that can occur in TRILL Hellos
[RFC6326bis].

D. Eastlake, et
al
[Page 28]

INTERNET-DRAFT
TRILL: Adjacency

LAN  P2P  Numb  Content
Item

---  ---  ----
------------

M
M     1    Area Addresses TLV with
area zero only

M
M     1    MT Port Capabilities TLV
containing a VLAN-FLAGs

sub-TLV

O
O    0-n   Other MT Port Capability TLVs

M
-    0-n   TRILL Neighbor TLV (see Section
8.2.1)

-
M     1    Three-Way Handshake
TLV

O
O    0-n   Protocols Supported TLV that MUST
list the TRILL

NLPID (0xC0) [RFC6328]

O
O    0-1   BFD Enabled TLV

O
O    0-1   Authentication TLV

-
-    0-n   Padding TLV, SHOULD NOT be
included

A TRILL Hello MAY also contain any TLV permitted in a Layer
3 IS-IS

Hello.  As with all IS-IS PDUs, TLVs that are
unsupported/unknown in

TRILL Hellos are ignored.

8.2 Transmitting TRILL Hellos

TRILL Hellos are sent with the same timing as Layer 3 IS-IS
Hellos

[IS-IS]; however, no Hellos are sent if a port is in the
Suspended or

Down states or if the port is disabled.

TRILL Hello PDUs SHOULD NOT be padded and MUST NOT be sent
exceeding

1,470 octets; however, a received TRILL Hello longer than
1,470

octets is processed normally.

TRILL Hello PDU headers MUST conform to the
following:

o  Maximum Area Addresses equal to
1.

o  Circuit Type equal to 1.

See Section 8.1 for mandatory and some optional Hello TLV
contents.

8.2.1 TRILL Neighbor TLVs

A TRILL Neighbor TLV should not be include in TRILL
point-to-point

Hellos as it MUST be ignored in that context and wastes
space.

TRILL Neighbor TLVs sent in a LAN Hello on an Ethernet link
MUST show

the neighbor information, as sensed by the transmitting
RBridge, for

the VLAN on which the Hello is sent.  Since
implementations

conformant to this document maintain such information on a
per-VLAN

D. Eastlake, et
al
[Page 29]

INTERNET-DRAFT
TRILL: Adjacency

basis only for the Designated VLAN, such implementations
only send

the TRILL Neighbor TLV in TRILL LAN Hellos in the Designated
VLAN.

It is RECOMMENDED that, if there is sufficient room, a TRILL
Neighbor

TLV or TLVs, as described in Section 4.4.2.1 of [RFC6325],
covering

the entire range of MAC addresses and listing all
adjacencies with a

non-zero Designated VLAN Hello Holding time, or an empty
list of

neighbors if there are no such adjacencies, be in TRILL
Hellos sent

on the Designated VLAN.  If this is not possible, then
TRILL Neighbor

TLV's covering sub-ranges of MAC addresses should be sent so
that the

entire range is covered reasonably promptly.  Delays in
sending TRILL

Neighbor TLVs will delay the advancement of adjacencies to
the Report

state and the discovery of some link failures.  Rapid
(for example,

sub-second) detection of link or node failures is best
addressed with

a protocol designed for that purpose, such as BFD (see
Section 6).

To ensure that any RBridge RB2 can definitively determine
whether RB1

can hear RB2, RB1's neighbor list MUST eventually cover
every

possible range of IDs, that is, within a period that depends
on RB1's

policy and not necessarily within any specific period such
as its

Holding Time.  In other words, if X1 is the smallest ID
reported in

one of RB1's neighbor lists, and the "smallest"
flag is not set, then

X1 MUST appear in a different neighbor list as well, as the
largest

ID reported in that fragment.  Or lists may overlap, as
long as there

is no gap, such that some range, say between Xi and Xj,
would never   appear in any list.

8.3 Receiving TRILL Hellos

Assuming a packet has the L2-IS-IS Ethertype and, if
received on

Ethernet, the All-IS-IS-RBridges multicast address, it will
be

examined to see if it appears to be an IS-IS PDU.  If
so, and it

appears to be a TRILL Hello PDU, the following tests are
performed.

o  The type of Hello PDU (LAN or P2P)
is compared with the port

configuration. If a LAN
Hello is received on a port configured

to be point-to-point or
a P2P Hello is received on a port not

configured to be
point-to-point, it is discarded.

o  If the Circuit Type field is not
1, the PDU is discarded.

o  If the PDU does not contain an
Area Address TLV or it contains

an Area Address TLV that
is not the single Area Address zero,

it is
discarded.

o  If the Hello includes a Protocols
Supported TLV that does not

list the TRILL NLPID
(0xC0), it is discarded.  It is acceptable

if there is no Protocols
Supported TLV present.

D. Eastlake, et
al
[Page 30]

INTERNET-DRAFT
TRILL: Adjacency

o  If the Hello does not contain
an

[a]
MT Port Capabilities TLV

containing a VLAN-FLAGS
sub-TLV [RFC6326bis], it is discarded.

o  If the maximumAreaAddresses field
of the PDU is not 1, it is

discarded.

o  If IS-IS authentication is in use
on the link and the PDU

either has no
Authentication TLV or validation of that

Authentication TLV
fails, it is discarded.

If none of the rules in the list above causes the packet to
be

discarded and it is parseable, it is assumed to be a
well-formed

TRILL Hello received on the link.  It is treated as an
event A0, A1,

A2, or A3 based on the criteria listed in Section
3.3.

D. Eastlake, et
al
[Page 31]

INTERNET-DRAFT
TRILL: Adjacency

9. Multiple Ports on the Same Broadcast Link

It is possible for an RBridge RB1 to have multiple ports on
the same

broadcast (LAN) link that are not in the Suspended
state.  It is

important for RB1 to recognize which of its ports are on the
same

link.  RB1 can detect this condition based on receiving
TRILL Hello

messages with the same LAN ID on multiple ports.

The DRB election is port-based (see Section 4) and only the
Hellos

from the elected port can perform certain functions such as
dictating

the Designated VLAN or whether a pseudonode will be used;
however,

the election also designates the RBridge with that port as
DRB for

the link. An RBridge may choose to load split some tasks
among its

ports on the link if it has more than one. Section 4.4.4 of
[RFC6325]

describes when it is safe to do so.

D. Eastlake, et
al
[Page 32]

INTERNET-DRAFT
TRILL: Adjacency

10. Security Considerations

This memo provides improved documentation of some aspects of
the

TRILL base protocol standard, particularly five aspects of
the TRILL

adjacency establishment and Hello protocol as listed in
Section 1.

It does not change the security considerations of the TRILL
base

protocol that are in Section 6 of [RFC6325].

See [RFCbfd] for security considerations for BFD whose use
in

connection with TRILL adjacency is discussed in this
document,

particularly Section 6.

11. IANA Considerations

This document requires no IANA Actions. RFC Edtior: Please
remove

this section before publication.

D. Eastlake, et
al
[Page 33]

INTERNET-DRAFT
TRILL: Adjacency

Appendix A: Changes from [RFC6327]

This document has the following changes from [RFC6327]. It
obsoletes

[RFC6327].

1. Extends the TRILL Hello size limit, MTU testing, and
state machine

to point-to-point links.

2. Incorporates the updates to [RFC6327] from
[RFCclear].

3. The bulk of [RFC6327] was written from the point of view
that

links between TRILL switches would only be
Ethernet. In fact, they

could be any technology, such as PPP
[RFC6361] or IP [TrillIP].

This replacement document generalizes
[RFC6327] to cover such link

types.

4. Includes a specification of one-hop BFD session
establishment in

connection with adjacency.

5. Numerous editorial changes.

D. Eastlake, et
al
[Page 34]

INTERNET-DRAFT
TRILL: Adjacency

Normative References

[IS-IS] - ISO/IEC 10589:2002, Second Edition,
"Intermediate System to

Intermediate System
Intra-Domain Routing Exchange Protocol for

use in Conjunction with
the Protocol for Providing the

Connectionless-mode
Network Service (ISO 8473)", 2002.

[RFC1195] - Callon, R., "Use of OSI IS-IS for routing
in TCP/IP and

dual environments",
RFC 1195, December 1990.

[RFC2119] - Bradner, S., "Key words for use in RFCs to
Indicate

Requirement
Levels", BCP 14, RFC 2119, March 1997.

[RFC6213] - Hopps, C. and L. Ginsberg, "IS-IS
BFD-Enabled TLV", RFC

6213, April
2011.

[RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and
A.

Ghanwani,
"RBridges: Base Protocol Specification", RFC 6325,

July 2011.

[RFC6328] - Eastlake 3rd, D., "IANA Considerations for
Network Layer

Protocol
Identifiers", BCP 164, RFC 6328, July 2011.

[RFCbfd] - Manral, V., D. Eastlake, D. Ward, A. Banerjee,
"TRILL

(Transparent
Interconnetion of Lots of Links): Bidirectional

Forwarding Detection
(BFD) Support", draft-ietf-trill-rbridge-

bfd, in RFC Editor's
queue.

[RFCchannel] - D. Eastlake, V. Manral, Y. Li, S. Aldrin, D.
Ward,

"TRILL: RBridge
Channel Support", draft-ietf-trill-rbridge-

channel-08.txt, in RFC
Editor's queue.

[RFCclear] - Eastlake, D., M. Zhang, A. Ghanwani, V. Manral,
A.

Banerjee, "TRILL:
Clarifications, Corrections, and Updates "

draft-ietf-trill-clear-correct, in RFC Editor's queue.

[RFC6326bis] - Eastlake, D., Banerjee, A., Dutt, D.,
Perlman, R., and

A. Ghanwani, "TRILL
Use of IS-IS", draft-ietf-isis-rfc6326bis,

work in
progress.

Informative References

[802.1AX] - "IEEE Standard for Local and metropolitan
area networks /

Link Aggregation",
802.1AX-2008, 1 January 2008.

[802.1Q] - "IEEE Standard for Local and metropolitan
area networks /

Media Access Control
(MAC) Bridges and Virtual Bridge Local

Area Networks",
802.1Q-2011, 31 August 2011.

D. Eastlake, et
al
[Page 35]

INTERNET-DRAFT
TRILL: Adjacency

[FCoE] - From
www.t11.org discussion
of "FCoE Max Size" generated

from T11/09-251v1,
04/27/2009, "FCoE frame or FCoE PDU".

[RFC3719] - Parker, J., Ed., "Recommendations for
Interoperable

Networks using
Intermediate System to Intermediate System (IS-

IS)", February
2004.

[RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A.,
Dutt, D.,

and V. Manral,
"Routing Bridges (RBridges): Adjacency", RFC

6327, July
2011.

[RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP
Transparent

Interconnection of Lots
of Links (TRILL) Protocol Control

Protocol", RFC
6361, August 2011.

[RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A.,
and F.

Hu, "Routing
Bridges (RBridges): Appointed Forwarders", RFC

6439, November
2011.

[RFCfgl] - D. Eastlake, M. Zhang, P. Agarwal, R. Perlman, D.
Dutt,

"TRILL (Transparent
Interconnection of Lots of Links): Fine-

Grained Labeling",
draft-ietf-trill-fine-labeling, work in

progress.

[ESADI] - Zhai, H., F. Hu, R. Perlman, D. Eastlake, O.
Stokes, "

TRILL (Transparent
Interconnection of Lots of Links): ESADI

(End Station Address
Distribution Information) Protocol",

draft-ietf-trill-esadi,
work in progress.

[TrillIP] - M. Wasserman, D. Eastlake, D. Zhang,
"Transparent

Interconnection of Lots
of Links (TRILL) over IP", draft-mrw-

trill-over-ip, work in
progress.

D. Eastlake, et
al
[Page 36]

INTERNET-DRAFT
TRILL: Adjacency

Acknowledgements

The suggestions and comments of the following are
gratefully

acknowledged:

Arnel Lim, Howard Yang

The acknowledgements section of [RFC6327] includes the
following

listed in alphabetic order: Jari Arkko, Ayan Banerjee, Les
Ginsberg,

Sujay Gupta, David Harrington, Pete McCann, Erik Nordmark,
and Mike

Shand.

The document was prepared in raw nroff. All macros used were
defined

within the source file.

D. Eastlake, et
al
[Page 37]

INTERNET-DRAFT
TRILL: Adjacency

Authors' Addresses

Donald E. Eastlake, 3rd

Huawei Technologies

155 Beaver Street

Milford, MA 01757 USA

Phone: +1-508-333-2270

EMail: [email-masked]

Radia Perlman

Intel Labs

2200 Mission College Blvd.

Santa Clara, CA 95054-1549 USA

Phone: +1-408-765-8080

EMail: [email-masked]

Anoop Ghanwani

Dell

350 Holger Way

San Jose, CA 95134 USA

Phone: +1-408-571-3500

EMail: [email-masked]

Vishwas Manral

Hewlett Packard Co.

19111 Pruneridge Ave,

Cupertino, CA 95014 USA

Phone: +1-408-447-1497

EMail: [email-masked]

D. Eastlake, et
al
[Page 38]

INTERNET-DRAFT
TRILL: Adjacency

Copyright, Disclaimer, and Additional IPR Provisions

Copyright (c) 2013 IETF Trust and the persons identified as
the

document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's
Legal

Provisions Relating to IETF Documents

(
http://trustee.ietf.org/license-info) in effect on the date of

publication of this document. Please review these
documents

carefully, as they describe your rights and restrictions
with respect

to this document. Code Components extracted from this
document must

include Simplified BSD License text as described in Section
4.e of

the Trust Legal Provisions and are provided without warranty
as

described in the Simplified BSD License.  The
definitive version of

an IETF Document is that published by, or under the auspices
of, the

IETF. Versions of IETF Documents that are published by third
parties,

including those that are translated into other languages,
should not

be considered to be definitive versions of IETF Documents.
The

definitive version of these Legal Provisions is that
published by, or

under the auspices of, the IETF. Versions of these Legal
Provisions

that are published by third parties, including those that
are

translated into other languages, should not be considered to
be

definitive versions of these Legal Provisions.  For the
avoidance of

doubt, each Contributor to the IETF Standards Process
licenses each

Contribution that he or she makes as part of the IETF
Standards

Process to the IETF Trust pursuant to the provisions of RFC
5378. No

language to the contrary, or terms, conditions or rights
that differ

from or are inconsistent with the rights and licenses
granted under

RFC 5378, shall have any effect and shall be null and void,
whether

published or posted by such Contributor, or included with or
in such

Contribution.

D. Eastlake, et
al
[Page 39]