wdiff rfc7783.alt-original rfc7783.txt

TRILL Working Group Tissa Senevirathne
Internet Draft Engineering Task Force (IETF) T. Senevirathne
Request for Comments: 7783 Consultant
Intended status: Standard Track Janardhanan Pathangi
Updates: 6325 DELL
Jon J. Pathangi
Category: Standards Track Dell
ISSN: 2070-1721 J. Hudson
Brocade

October 18, 2015
Expires: April2016
February 2016

Coordinated Multicast Trees (CMT)
for TRILL
draft-ietf-trill-cmt-11.txt Transparent Interconnection of Lots of Links (TRILL)

Abstract

TRILL (Transparent Interconnection of Lots of Links) facilitates loop free
loop-free connectivity to non-TRILL networks via a choice of an
Appointed Forwarder for a set of VLANs. Appointed Forwarders provide
VLAN-based load sharing based on VLAN with an active-standby model. High High-
performance applications require an active-active load-
sharing load-sharing model.
The Active-Active active-active load-sharing model can be accomplished by
representing any given non-TRILL network with a single virtual RBridge.
RBridge (also referred to as a virtual Routing Bridge or virtual
TRILL switch). Virtual representation of the non-TRILL network with
a single RBridge poses serious challenges in multi-
destination multi-destination RPF
(Reverse Path Forwarding) check calculations. This document
specifies required enhancements to build Coordinated Multicast Trees
(CMT) within the TRILL campus to solve related RPF issues. CMT,
which only requires a software upgrade, provides flexibility to
RBridges in selecting a desired path of association to a given TRILL
multi-destination distribution tree. This document updates RFC 6325.

Status of this This Memo

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

Internet-Drafts are working documents an Internet Standards Track document.

This document is a product 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
(IETF). It represents the consensus of six
months the IETF community. It has
received public review and may be updated, replaced, or obsoleted has been approved for publication by other documents
at any time. It the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work available in progress."

The list Section 2 of RFC 5741.

Information about the current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list status of Internet-Draft Shadow Directories can this document, any errata,
and how to provide feedback on it may be accessed obtained at
http://www.ietf.org/shadow.html

This Internet-Draft will expire on April 18,2009.
http://www.rfc-editor.org/info/rfc7783.

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.

Table of Contents

1. Introduction ..................................................3 ....................................................3
1.1. Scope and Applicability ..................................5 ....................................4
2. Conventions used Used in this document .............................5 This Document ...............................5
2.1. Acronyms and Phrases .....................................5 .......................................5
3. The AFFINITY sub-TLV ..........................................6 Affinity Sub-TLV ............................................6
4. Multicast Tree Construction and Use of Affinity Sub-TLV .......7 .........6
4.1. Update to RFC 6325 .......................................8 .........................................7
4.2. Announcing virtual Virtual RBridge nickname ......................9 Nickname ........................8
4.3. Affinity Sub-TLV Capability ..............................9 ................................8
5. Theory of operation ..........................................10 Operation .............................................8
5.1. Distribution Tree Assignment ............................10 ...............................8
5.2. Affinity Sub-TLV advertisement ..........................10 Advertisement .............................9
5.3. Affinity sub-TLV conflict resolution ....................11 Sub-TLV Conflict Resolution .......................9
5.4. Ingress Multi-Destination Forwarding ....................11 ......................10
5.4.1. Forwarding when n < k ..............................12 ..............................10
5.5. Egress Multi-Destination Forwarding .....................12 .......................11
5.5.1. Traffic Arriving on an assigned Assigned Tree to RBk-RBv ....12 ....11
5.5.2. Traffic Arriving on other Other Trees ....................12 ....................11
5.6. Failure scenarios .......................................13 Scenarios .........................................11
5.6.1. Edge RBridge RBk failure ...........................13 Failure ...........................11
5.7. Backward compatibility ..................................14 Compatibility ....................................12
6. Security Considerations ......................................14 ........................................13
7. IANA Considerations ..........................................15 ............................................13
8. References ...................................................15 .....................................................14
8.1. Normative References ....................................15 ......................................14
8.2. Informative References ..................................16
Appendix A. Change History ......................................17 ....................................15
Acknowledgments ..............................................16 ...................................................16
Contributors .................................................. ......................................................16
Authors' Addresses ................................................16

1. Introduction

TRILL (Transparent Interconnection of Lots of Links) Links), as presented in
[RFC6325] and other related documents, provides methods of utilizing
all available paths for active forwarding, with minimum
configuration. TRILL utilizes IS-IS (Intermediate System to
Intermediate System [IS-IS]) System) [IS-IS] as its control plane and uses a TRILL
header with hop count.
Header that includes a Hop Count.

[RFC6325], [RFC7177], and [RFC6439] provide methods for
interoperability between TRILL and Ethernet end stations and bridged
networks. [RFC6439] provides an active-standby solution, where only
one of the RBridges (aka Routing Bridges or TRILL switches) on a link
with end stations is in the active forwarding state for end station end-station
traffic for any given VLAN. That RBridge is referred to as the
Appointed Forwarder (AF). All frames ingressed into a TRILL network
via the Appointed Forwarder AF are encapsulated with the TRILL header Header with a nickname
held by the ingress AF RBridge. Due to failures, re-configurations reconfigurations,
and other network dynamics, the Appointed Forwarder AF for any set of VLANs may change.
RBridges maintain forwarding tables that contain bindings for
destination
MAC address Media Access Control (MAC) addresses and Data Label Labels
(VLAN or Fine Grained Label (FGL)) Fine-Grained Labels (FGLs)) to egress RBridge binding. RBridges. In the
event of an AF change, forwarding tables of remote RBridges may
continue to forward traffic to the previous AF and that AF. That traffic may get
discarded at the egress, causing traffic disruption.

High performance

High-performance applications require resiliency during failover.
The active-active forwarding model minimizes impact during failures
and maximizes the available network bandwidth. A typical deployment
scenario, depicted in Figure 1, may have either End Stations end stations and/or bridges
attached to the RBridges. These devices typically are multi-homed to
several RBridges and treat all of the uplinks independently using a
Local Active-Active Link Protocol (LAALP
[RFC7379]) (LAALP) [RFC7379], such as a single
Multi-Chassis Link Aggregation (MC-LAG) bundle or Distributed
Resilient Network Interconnect [8021AX]. [802.1AX]. The
Appointed Forwarder AF designation
presented in [RFC6439] requires each of the edge RBridges to exchange
TRILL Hello packets. By design, an LAALP does not forward packets
received on one of the member ports of the MC-LAG to other member
ports of the same MC-LAG. As a result result, the AF designation methods
presented in [RFC6439] cannot be applied to the deployment scenario
depicted in Figure 1. [RFC7379]

An active-active load-sharing model can be implemented by
representing the edge of the network connected to a specific edge
group of RBridges by a single virtual RBridge. Each virtual RBridge
MUST have a nickname unique within its TRILL campus. In addition to
an active-active forwarding model, there may be other applications
that may requires require similar representations.

Sections 4.5.1 and 4.5.2 of [RFC6325] [RFC6325], as updated by [RFC7180bis] [RFC7780],
specify distribution tree calculation and RPF (Reverse Path
Forwarding) check calculation algorithms for multi-destination
forwarding. These algorithms strictly depend on link cost and parent
RBridge priority. As a result, based on the network topology, it may
be possible that a given edge RBridge, if it is forwarding on behalf
of the virtual RBridge, may not have a candidate multicast tree that
the on
which it (the edge RBridge RBridge) can forward traffic on traffic, because there is no
tree for which the virtual RBridge is a leaf node from the edge
RBridge.

In this document document, we present a method that allows RBridges to specify
the path of association for real or virtual child nodes to
distribution trees. Remote RBridges calculate their forwarding
tables and derive the RPF for distribution trees based on the
distribution tree association advertisements. In the absence of
distribution tree association advertisements, remote RBridges derive
the SPF (Shortest Path First) based on the algorithm specified in
section
Section 4.5.1 of [RFC6325] [RFC6325], as updated by [RFC7180bis]. [RFC7780]. This document
updates [RFC6325] by changing, when CMT Coordinated Multicast Trees (CMT)
sub-TLVs are present, [RFC6325] mandatory provisions as to how
distribution tree trees are constructed.

Other applications, beside

In addition to the above mentioned above-mentioned active-active forwarding model,
other applications may utilize the distribution tree association
framework presented in this document to associate to distribution
trees through a preferred path.

This proposal requires (1) the presence of multiple multi-destination
trees within the TRILL campus and updating (2) that all the RBridges in the
network be updated to support the new Affinity sub-TLV (Section 3. ). 3).
It is expected that both of these requirements will be met met, as they
are
control plane changes, control-plane changes and will be common deployment scenarios.
In case either of the above two conditions are is not met, RBridges MUST
support a fallback option for interoperability. Since the fallback
is expected to be a temporary phenomenon till until all RBridges are
upgraded, this proposal gives guidelines for such fallbacks, fallbacks and does
not mandate or specify any specific set of fallback options.

1.1. Scope and Applicability

This document specifies an Affinity sub-TLV to solve RPF issues at
the active-active edge. Specific methods in this document for making
use of the Affinity sub-TLV are applicable where a virtual RBridge is
used to represent multiple RBridges connected to an edge CE Customer
Ethernet (CE) device through an LAALP LAALP, such as multi-chassis link aggregation MC-LAG or some similar
arrangement where the RBridges cannot see each other's Hellos.

This document does not provide other required operational elements to
implement an active-active edge solution, such as methods of
multi-chassis link aggregation. Solution specific MC-LAG methods.
Solution-specific operational elements are outside the scope of this
document and will be covered in other documents. (See, for example [TRILLPN].) example,
[RFC7781].)

Examples provided in this document are for illustration purposes
only.

2. Conventions used Used in this document This Document

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

In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case Lowercase uses of these words are not to be
interpreted as carrying [RFC2119] significance.

2.1. Acronyms and Phrases

The following acronyms and phrases are used in this document:

AF: Appointed Forwarder [RFC6439].

CE: Customer Ethernet device, that is, a device that performs
forwarding based on 802.1Q bridging. This also can be end-station an
end station or a server.

Data Label: VLAN or FGL.

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

LAALP: Local Active-Active Link Protocol [RFC7379].

MC-LAG: Multi-Chassis Link Aggregation is a Aggregation. A proprietary extension to
[8021AX],
[802.1AX] that facilitates connecting a group of links from an
originating device (A) to a group of discrete devices (B).
Device (A)
treats, treats all of the links in a given Multi-Chassis Link Aggregation MC-LAG bundle as a
single logical interface and treats all devices in Group (B) as a
single logical device for all forwarding purposes. Device (A)
does not forward packets receive received on Multi-Chassis Link the multi-chassis link bundle
out of the same Multi-Chassis multi-chassis link bundle. Figure 1 depicts a
specific use case example.

RPF: Reverse Path Forwarding. See section Section 4.5.2 of [RFC6325].

Virtual RBridge: A purely conceptual RBridge that represents an
Active-Active Edge
active-active edge group and is in turn represented by a nickname.
For example, see [PseudoNickname]. [RFC7781].

3. The AFFINITY sub-TLV Affinity Sub-TLV

Association of an RBridge to a multi-destination distribution tree
through a specific path is accomplished by using a new IS-IS sub-
TLV, sub-TLV,
the Affinity sub-TLV.

The AFFINITY Affinity sub-TLV appears in Router Capability TLVs or
MT Capability TLVs that are within LSP PDUs, Link State PDUs (LSPs), as
described in [RFC7176]. [RFC7176]
which specifies the code point and data
structure for the Affinity sub-TLV.

4. Multicast Tree Construction and Use of Affinity Sub-TLV

Figure

Figures 1 and Figure 2 below show the reference topology and a logical
topology using CMT to provide active-active service.

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

--------------------
/ \
| |
| TRILL Campus |
| |
\ /
--------------------
| | |
----- | --------
| | |
+------+ +------+ +------+
| | | | | |
|(RB1) | |(RB2) | | (RBk)|
+------+ +------+ +------+
|..| |..| |..|
| +----+ | | | |
| +---|-----|--|----------+ |
| +-|---|-----+ +-----------+ |
| | | +------------------+ | |
(| | |) <-- MC-LAG (| | |) <- <-- MC-LAG
+-------+ . . . +-------+
| CE1 | | CEn |
| | | |
+-------+ +-------+

Figure 1 1: Reference Topology
------------------
-------------------- Sample Multicast Tree (T1)
/ \
| | |
| TRILL Campus | o RBn
| | / | \
\ / / | ---\
--------------------- RB1o
-------------------- RB1 o o o
| | | | RB2 RBk
| | -------------- |
| | | oRBv o RBv
+------+ +------+ +------+
| | | | | |
|(RB1) | |(RB2) | | (RBk)|
+------+ +------+ +------+
|..| |..| |..|
| +----+ | | | |
| +---|--|--|-------------+ |
| +-|---|--+ +--------------+ |
MC-
| | | +------------------+ | |
LAG--->(|
MC-LAG -->(| | |) (| | |)<- |)<-- MC-LAG
+-------+ . . . +-------+
| CE1 | | CEn |
| | | |
+-------+ +-------+

RBv: virtual RBridge

Figure 2 2: Example Logical Topology

4.1. Update to RFC 6325

This document updates Section 4.5.1 of [RFC6325], is updated to change [RFC6325] and changes the
calculation of distribution trees trees, as specified below:

Each RBridge that desires to be the parent RBridge for a child
RBridge RBy (RBy) in a multi-destination distribution tree x (Tree x)
announces the desired association using an Affinity sub-TLV. The
child is specified by its nickname. If an RBridge RB1 (RB1) advertises
an AFFINITY Affinity sub-TLV designating one of its own nicknames N1 (N1) as its ''child''
"child" in some distribution tree, the effect is that that nickname N1 is
ignored when constructing other distribution trees. Thus Thus, the
RPF check will enforce the rule that only RB1 can use nickname N1 to
do ingress/egress on
tree Tree x. (This has no effect on least cost least-cost path
calculations for unicast traffic.)

When such an Affinity sub-TLV is present, the association specified
by the affinity Affinity sub-TLV MUST be used when constructing the multi-
destination
multi-destination distribution tree tree, except in the case of a
conflicting Affinity
sub-TLV, which sub-TLV; such cases are resolved as specified in
Section 5.3. In the absence of such an Affinity sub-TLV, or if there
are any RBridges in the campus that do not support the Affinity
sub-TLV, distribution trees are calculated as specified in the section
Section 4.5.1 of [RFC6325] [RFC6325], as updated by [RFC7180bis]. [RFC7780]. Section 4.3. 4.3
below specifies how to identify RBridges that support the Affinity sub-TLV capability.
sub-TLV.

4.2. Announcing virtual Virtual RBridge nickname Nickname

Each edge RBridge RB1 (RB1 to RBk RBk) advertises in its LSP virtual RBridge
nickname RBv (RBv) by using the Nickname sub-TLV (6), (6) [RFC7176], along
with their regular nickname or nicknames.

It will be possible for any RBridge to determine that RBv is a
virtual RBridge RBridge, because each RBridge (RB1 to RBk) this that appears to be
advertising that it is holding RBv is also advertising an Affinity
sub-TLV asking that RBv be its child in one or more trees.

Virtual RBridges are ignored when determining the distribution tree
roots for the campus.

All RBridges outside the edge group assume that multi-destination
packets with ingress nickname their TRILL Header Ingress Nickname field set to RBv
might use any of the distribution trees that any member of the edge
group is advertising advertises that it might use.

4.3. Affinity Sub-TLV Capability. Capability

RBridges that announce the TRILL version Version sub-TLV [RFC7176] and set
the Affinity capability bit (Section 7. ) 7) support the Affinity sub-
TLV and sub-TLV,
calculation of multi-destination distribution trees trees, and RPF
checks checks,
as specified herein.

5. Theory of operation Operation

5.1. Distribution Tree Assignment

Let's assume that there are n distribution trees and k edge RBridges
in the edge group of interest.

If n >= k

Let's assume that edge RBridges are sorted in numerically
ascending order by IS-IS System ID such that RB1 < RB2 < RBk.
Each RBridge in the numerically sorted list is assigned a
monotonically increasing number j such that; RB1=0, RB2=1, RBi=j that RB1 = 0, RB2 = 1,
RBi = j, and
RBi+1=j+1. RBi + 1 = j + 1. (See Section 4.5 of [RFC6325] [RFC6325], as modified
updated by Section 3.4 of [RFC7180bis] [RFC7780], for how tree numbers are
determined.)

Assign each tree to RBi such that tree number
(((tree_number) %
k)+1) k) + 1) is assigned to edge group RBridge i for
tree_number from 1 to n. n, where n is the number of trees, k is the
number of edge group RBridges considered for tree allocation, and ''%''
"%" is the integer division remainder operation.

If n < k

Distribution trees are assigned to edge group RBridges RB1 to RBn,
using the same algorithm as the n >= k case. RBridges RBn+1 RBn + 1 to
RBk do not participate in the active-active forwarding process on
behalf of RBv.

5.2. Affinity Sub-TLV advertisement Advertisement

Each RBridge in the RB1 through RBk domain advertises an Affinity
TLV
sub-TLV for RBv to be its child.

As an example, let's assume that RB1 has chosen Trees t1 and tk+1 tk + 1
on behalf of RBv.

RB1 advertises affinity TLV; the Affinity sub-TLV;
{RBv, Num of Trees=2, Trees = 2, t1, tk+1. tk + 1}.

Other RBridges in the RB1 through RBk edge group follow the same
procedure.

5.3. Affinity sub-TLV conflict resolution Sub-TLV Conflict Resolution

In TRILL, multi-destination distribution trees are built outward from
the root by each RBridge so that they all derive the same set of
distribution trees [RFC6325].

If an RBridge RB1 advertises an Affinity sub-TLV with an AFFINITY RECORD
that asks for RBridge RBroot to be its child in a tree rooted at
RBroot, that AFFINITY RECORD is in conflict with TRILL distribution
tree root determination and MUST be ignored.

If an RBridge RB1 advertises an Affinity sub-TLV with an AFFINITY RECORD
that asks for nickname RBn to be its child in any tree and RB1 is neither not
adjacent to RBn nor does nickname RBn identify RB1 itself, that
AFFINITY RECORD is in conflict with the campus topology and MUST be
ignored.

If different RBridges advertise Affinity sub-TLVs that try to
associate the same virtual RBridge as their child in the same tree or
trees, those Affinity sub-TLVs are in conflict with each other for
those trees. The nicknames of the conflicting RBridges are compared
to identify which RBridge holds the nickname that is the highest
priority to be a tree root, with the System ID as the
tiebreaker tiebreaker.

The RBridge with the highest priority to be a tree root will retain
the Affinity association. Other RBridges with lower priority to be a
tree root MUST stop advertising their conflicting Affinity sub-TLV,
re-calculate sub-TLVs,
recalculate the multicast tree affinity allocation, and, if
appropriate, advertise a new non-conflicting Affinity sub-TLV. sub-TLVs.

Similarly, remote RBridges MUST honor the Affinity sub-TLV from the
RBridge with the highest priority to be a tree root (use system-ID (using System ID
as the tie-breaker tiebreaker in the event of conflicting priorities) and ignore
the conflicting Affinity sub-TLV entries advertised by the RBridges
with lower priorities to be tree roots.

5.4. Ingress Multi-Destination Forwarding

If there is at least one tree on which RBv has affinity via RBk, then
RBk performs the following operations, operations for multi-destination frames
received from a CE node:

1. Flood to locally attached CE nodes subjected to VLAN and multicast
pruning.

2. Ingress in the (by encapsulating with a TRILL header Header) and assign ingress RBridge nickname as set the Ingress
Nickname field of the TRILL Header to RBv (nickname (the nickname of the
virtual RBridge).

3. Forward to one of the distribution trees, tree x Tree x, in which RBv is
associated with RBk.

5.4.1. Forwarding when n < k

If there is no tree on which RBv can claim affinity via RBk (probably
because the number of trees n (n) built is less than the number of
RBridges k (k) announcing the affinity Affinity sub-TLV), then RBk MUST fall
back to one of the following following:

1. This RBridge (RBk) should stop forwarding frames from the CE nodes, nodes
and should mark that its port towards those CE nodes as disabled. This
will prevent the CE nodes from forwarding data on to this RBridge, and RBridge.
Thus, the CE nodes will only use those RBridges which that have been
assigned a tree - tree.

-OR-

2. This RBridge tunnels multi-destination frames received from
attached native devices to an RBridge RBy that has an assigned
tree. The tunnel destination should forward it to the TRILL
network,
network and also to its local access links. (The mechanism of
tunneling and handshake handshaking between the tunnel source and
destination are out of scope of for this specification and may be
addressed in other documents documents, such as [ChannelTunnel].)

Above

The above fallback options may be specific to the active-active
forwarding scenario. However, as stated above, the Affinity sub-TLV
may be used in other applications. In such event an event, the application
SHOULD specify applicable fallback options.

5.5. Egress Multi-Destination Forwarding

5.5.1. Traffic Arriving on an assigned Assigned Tree to RBk-RBv

Multi-destination frames arriving at RBk on a Tree x, where RBk has
announced the affinity of RBv via x, MUST be forwarded to CE members
of RBv that are in the frame's VLAN. Forwarding to other end-nodes end nodes
and RBridges that are not part of the network represented by the RBv
virtual RBridge nickname (RBv) MUST follow the forwarding rules
specified in [RFC6325].

5.5.2. Traffic Arriving on other Other Trees

Multi-destination frames arriving at RBk on a Tree y, where RBk has
not announced the affinity of RBv via y, MUST NOT be forwarded to CE
members of RBv. Forwarding to other end-nodes end nodes and RBridges that are
not part of the network represented by the RBv virtual RBridge nickname
(RBv) MUST follow the forwarding rules specified in [RFC6325].

5.6. Failure scenarios Scenarios

The below failure recovery algorithm below is presented only as a
guideline. An active-active edge group MAY use other failure
recovery algorithms; it is recommended that only one algorithm be
used in an edge group at a time. Details of such algorithms are
outside the scope of this document.

5.6.1. Edge RBridge RBk failure Failure

Each of the member RBridges of a given virtual RBridge edge group is
aware of its member RBridges through configuration, LSP
advertisements, or some other method.

Member RBridges detect nodal failure of a member RBridge through IS-
IS
IS-IS LSP advertisements or lack thereof.

Upon detecting a member failure, each of the member RBridges of the
RBv edge group start recovery timer T_rec for failed RBridge RBi. If
the previously failed RBridge RBi has not recovered after the expiry
of timer T_rec, members member RBridges perform the distribution tree
assignment algorithm specified in section Section 5.1. Each of the member
RBridges re-advertises the Affinity sub-TLV with the new tree
assignment. This action causes the campus to update the tree
calculation with the new assignment.

RBi, upon start-up, startup, advertises its presence through IS-IS LSPs and
starts a timer T_i. Other member RBridges of the edge group,
detecting the presence of RBi, start a timer T_j.

Upon expiry of timer T_j, other member RBridges recalculate the
multi-destination tree assignment and advertised advertise the related trees
using the Affinity sub-TLV. Upon expiry of timer T_i, RBi recalculate
recalculates the multi-destination tree assignment and advertises the
related trees using the Affinity TLV. sub-TLV.

If the new RBridge in the edge group calculates trees and starts to
use one or more of them before the existing RBridges in the edge
group recalculate, there could be duplication of packets (for example
example, more than one edge group RBridge could decapsulate and
forward a multi-destination frame on links into the active-active
group) or loss of packets (for example example, due to the Reverse Path
Forwarding
Check check, in the rest of the campus campus, if two edge group
RBridges are trying to forward on the same tree tree, those from one will
be discarded). Alternatively, if the new RBridge in the edge group
calculates trees and starts to use one or more of them after the
existing RBridges recalculate, there could be loss of data due to
frames arriving at the new RBridge being black holed. black-holed. Timers T_i and
T_j should be initialized to values designed to minimize these problems
problems, keeping in mind that, in general, duplicating duplication of packets is
a more serious problem than dropping. dropped packets. It is RECOMMENDED that
T_j be less than T_i T_i, and a reasonable default is 1/2 of T_i.

5.7. Backward compatibility Compatibility

Implementations MUST support a backward compatibility mode modes to
interoperate with pre Affinity sub-TLV "pre-Affinity sub-TLV" RBridges in the network.
Such backward compatibility operation operations MAY include, however is but are not
limited to, tunneling and/or active-standby modes of operations. operation. It
should be noted that tunneling would require silicon changes.
However, CMT in itself is a software upgrade.

Example:

Step 1. Stop using the virtual RBridge nickname for traffic
ingressing from CE nodes nodes.

Step 2. Stop performing active-active forwarding. And fall Fall back to
active standby forwarding, based on locally defined policies.
Definition The
definition of such policies is outside the scope of this document
and may be addressed in other documents.

6. Security Considerations

In general, the RBridges in a campus are trusted routers routers, and the
authenticity of their link state link-state information (LSPs) and link local link-local
PDUs (Hellos, etc.) (e.g., Hellos) can be enforced using regular IS-IS security
mechanisms [IS-IS] [RFC5310]. This including includes authenticating the
contents of the PDUs used to transport Affinity sub-TLVs.

The particular Security Considerations security considerations involved with different
applications of the Affinity sub-TLV will be covered in the
document(s) specifying those applications.

For general TRILL Security Considerations, security considerations, see [RFC6325].

7. IANA Considerations

This document serves as the reference for "TRILL-VER Sub-TLV
Capability Flags" the registration of
"Affinity sub-TLV support." support" (bit 0)
so that reference should be updated when this document is published
as an RFC. in the "TRILL-VER Sub-TLV
Capability Flags" registry.

This document mentions the registration of "AFFINITY" (value 17) in
the "Sub-TLVs for TLV 144" registration
"AFFINITY" (value 17), registry, but should it is intentionally not be
listed as a reference for that registration which should remain registration; the reference remains
[RFC7176].

8. References

8.1. Normative References

[IS-IS] International Organization for Standardization,
ISO/IEC 10589:2002, "Information technology --
Telecommunications and information exchange between
systems -- Intermediate System to Intermediate System
intra-domain routeing information exchange protocol for
use in conjunction with the protocol for providing the
connectionless-mode network service", ISO 8473,
Second Edition, 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. 1997,
<http://www.rfc-editor.org/info/rfc2119>.

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

[RFC6325] Perlman, R., et.al. ''RBridge: Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification'',
Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011.

[RFC7177] Eastlake 3rf, D. et.al., ''RBridge: Adjacency'', RFC 7177,
May 2014. 2011,
<http://www.rfc-editor.org/info/rfc6325>.

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

[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. et.al., ''Transparent D., Senevirathne, T., Ghanwani, A., Dutt,
D., and A. Banerjee, "Transparent Interconnection of Lots
of Links (TRILL) Use of IS-IS'', IS-IS", RFC 7176,
DOI 10.17487/RFC7176, May 2014.

[RFC7180bis] 2014,
<http://www.rfc-editor.org/info/rfc7176>.

[RFC7177] Eastlake 3rd, D. et.al., ''TRILL: 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>.

[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'', draft-ietf-trill-rfc7180bis,
work in progress.

[IS-IS] ISO/IEC, ''Intermediate System to Intermediate System Routing
Information Exchange Protocol for use in Conjunction with
the Protocol for Providing the Connectionless-mode Network
Service (ISO 8473)'' ISO/IEC 10589:2002.

[PseudoNickname] H.
Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
<http://www.rfc-editor.org/info/rfc7780>.

[RFC7781] Zhai, T. H., Senevirathne, R. T., Perlman, M. R., Zhang, M., and Y.
Li, "TRILL: "Transparent Interconnection of Lots of Links (TRILL):
Pseudo-Nickname for Active-Active Access",
draft-ietf-trill-pseudonode-nickname, in RFC Editor's
queue. 7781,
DOI 10.17487/RFC7781, February 2016,
<http://www.rfc-editor.org/info/rfc7781>.

8.2. Informative References

[802.1AX] IEEE, "IEEE Standard for Local and metropolitan area
networks - Link Aggregation", IEEE Std 802.1AX-2014,
DOI 10.1109/IEEESTD.2014.7055197, December 2014.

[ChannelTunnel]
Eastlake 3rd, D., Umair, M., and Y. Li, "TRILL: RBridge
Channel Tunnel Protocol", Work in Progress,
draft-ietf-trill-channel-tunnel-07, August 2015.

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

[TRILLPN] Zhai, H., et.al ''RBridge: Pseudonode Nickname'', draft-hu-
trill-pseudonode-nickname, Work in progress, November
2011.

[8021AX] IEEE, ''Link Aggregation'', IEEE Std 802.1AX-2014,
December 2014.

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

Appendix A. Change History.

From -01 to -02:

Replaced all references to ''LAG'' with references to Multi-Chassis
(MC-LAG) or the like.

Expanded, Security Considerations section.

Other editorial changes.

From -02 to -03

Minor editorial changes

From -03 to -04

Minor editorial changes and version update.

From -04 to -05

Editorial, reference, and other minor changes based on Document
Shepherd review.

From -05 to -6

Minor editorial fixes.

From -06 to -07

Clarifications primarily based on AD review.

From -08 to -09 to -10

IANA Considerations updated based on IANA feedback. Typos fixed
based on IESG, GENART and SECDIR reviews.

From -10 to -11

Editorial changes based on IESG review. DOI 10.17487/RFC7379,
October 2014, <http://www.rfc-editor.org/info/rfc7379>.

Acknowledgments

Authors

The authors wish to extend their appreciations towards individuals
who volunteered to review and comment on the work presented in this
document and who provided constructive and critical feedback.
Specific
acknowledgements acknowledgments are due for Anoop Ghanwani, Ronak Desai,
Gayle Noble, and Varun Shah. Very special Thanks thanks to Donald Eastlake
for his careful review and constructive comments.

This document was prepared using 2-Word-v2.0.template.dot.

Contributors

The work in this document is a result of many passionate discussions
and contributions from the following individuals. Their names are individuals, listed in
alphabetical order: order by their first names:

Ayan Banerjee, Dinesh Dutt, Donald Eastlake, Hongjun Zhai, Mingui
Zhang, Radia Perlman, Sam Aldrin, Shivakumar Sundaram, and Zhai Hongjun. Shivakumar Sundaram.

Authors' Addresses

Tissa Senevirathne
Consultant

Email: tsenevir@gmail.com

Janardhanan Pathangi
Dell/Force10 Networks
Olympia Technology Park, Park
Guindy Chennai 600 032
India

Phone: +91 44 4220 8400
Email:Pathangi_Janardhanan@Dell.com +91-44-42208400
Email: Pathangi_Janardhanan@Dell.com

Jon Hudson
Brocade
130 Holger Way
San Jose, CA 95134 USA
United States

Phone: +1-408-333-4062
Email:jon.hudson@gmail.com
Email: jon.hudson@gmail.com