Subject: [trill] Fwd: How Trill works step by step?

From: Donald Eastlake <[email-masked]>
Date: Fri, 11 Jul 2014 14:44:15 -0400

I got a query message recently which I am reposting with permission in
an edited form on the theory that it might be of interest to one or
more other people on the list.

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

> I need guidance from you.

I will try to answer your questions but there are lots of things in
TRILL that are implementation dependent. That is, TRILL lets the
implementor decide what they want to do.

> ->Unable to understand exact Trill step by step process.
>     E.g. Suppose we have developed Trill program and run it on different
> machines.Then what happened 1st ,Is LSP  or ESADI start first? -> Db
> creation -> Rbridge election(How to set priority? any fixed process ot
> depends on user settings? ) -> etc ?

The first thing that happens on a link is any link set-up that is
needed. For example, on a PPP link (RFC6361), you need to negotiate
that you will be using TRILL. However, if you have Ethernet links (RFC
6325), which are probably the most common type, there isn't any link
set-up needed.

Then TRILL IS-IS Hellos get exchanged on the link (RFC 7177).
Optionally, you might also exchange MTU-probe/ack PDUs (RFC 7177), BFD
PDUs (RFC 7175), or other link test packets. But all these other
things are optional. Only Hellos are required.

TRILL doesn't send anything else on the link until the link gets out
of the Down or Detect states (RFC 7177).

If a link is configured as a point-to-point link, there is no DRB
election. By default, an Ethernet link is considered a LAN link and
the DRB election occurs when the link is in any state other than Down.
You don't have to configure priorities for each TRILL switch (RBridge)
to be DRB. Things will work fine with all the RBridges on a link using
default priority. But if the network manager wants to control this,
they should be able to configure the priorities to be DRB.

(To avoid complexity, I'm generally describing things for a link which
only has two TRILL switches on it. But TRILL works fine as currently
specified on a broadcast link with multiple TRILL switches on it -
actually multiple TRILL switch ports since a TRILL switch can have
multiple ports connected to the same link. The most likely way to get
such a link with current technology is to have more than 2 TRILL
switch Etherenet ports connected to a bridged LAN. Since the TRILL
protocol operates above bridging, to the first approximation, the
bridge LAN looks like a single transparent broadcast link to TRILL.)

When the link gets to the 2-Way or Report state, then LSPs, CSNPs, and
PSNPs start to flow on the link.

When it gets to the Report state, then there is adjacency. The
existence of that adjacency is flooded (reported) to the campus in
LSPs. TRILL data packets can then start to flow on the link as TRILL
switches recalculates the least cost paths and distribution trees to
take the new adjacency into account. (Until it gets to the Report
state, there is no adjacency and no TRILL data can flow over that
link (with the minor corner case exception that an RBridge Channel
message can, for its first hop, be sent on a port where there is no
adjacency (RFC 7178, Section 2.4).) (Although this paragraph seems to
be talking about link state, it is actually port state. It is possible
for TRILL switch ports on a link to be in different states. The
adjacency state machinery runs independently on each port.)

ESADI is built on top of the regular TRILL routing. Since ESADI PDUs
look, to transit TRILL switches, like regular TRILL data packets, no
ESADI PDUs can flow until adjacencies are established and TRILL data
is flowing. Of course, ESADI is optional and is not used unless
configured...

> ->Does It required Trill Full header at the time of Trill-LSP starting to
> broadcast itself on link?Because at that time its not defined Egress and
> Ingress nicknames.

Well, I think that in most implementations, a TRILL switch will start
up using the same nickname it had when it shut down or last got
disconnected from a campus. If you want, you can implement TRILL to
come up initially not reporting any nickname until you get the link
state database or most of the link state database, and then choose a
nickname no other TRILL switch in the campus is using. Of course, if a
TRILL switch does not have a nickname, then it cannot ingress
data, cannot egress known unicast data, and cannot be a tree root.

TRILL IS-IS and LSPs and the link state data base all work based on
the 7-byte IS-IS System-ID (sometimes called the LAN ID). System-IDs
always have to be unique across the campus. The Nickname system is
built on top of that.

> ->What are the port nos in trill?

Port numbers are just arbitrary 16-bit numbers assigned by a TRILL
switch to its ports. The only requirements are that the numbers be
stable and that no two ports on the same TRILL switch have the same
port number. I believe they are only needed for some complex cases
involving duplicated port MAC addresses. For example, if a TRILL
switch with Ethernet ports uses the same MAC address for all of its
ports (not recommended) and two or more of those ports are connected
to the same link, the TRILL port number in the Hellos sent on those
ports are the only way for some other receiver to tell them apart. (If
multiple TRILL ports on a LAN link have the same MAC address, all but
one of them will be put in the Suspended state (RFC 7177).) The port
number (or Port ID as it is called in TRILL) appears in the Special
VLANs and Flags TLV (RFC 7176) that must appear in TRILL Hellos.