Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL)
RFC 8243

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, akatlas@gmail.com, trill-chairs@ietf.org, draft-ietf-trill-rbridge-multilevel@ietf.org, trill@ietf.org, shares@ndzh.com, rfc-editor@rfc-editor.org
Subject: Document Action: 'Alternatives for Multilevel TRILL (Transparent Interconnection of Lots of Links)' to Informational RFC (draft-ietf-trill-rbridge-multilevel-07.txt)

The IESG has approved the following document:
- 'Alternatives for Multilevel TRILL (Transparent Interconnection of Lots
   of Links)'
  (draft-ietf-trill-rbridge-multilevel-07.txt) as Informational RFC

This document is the product of the Transparent Interconnection of Lots of
Links Working Group.

The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/


Technical Summary

   Extending TRILL to multiple levels has challenges that are not
   addressed by the already-existing capability of IS-IS to have
   multiple levels.  One issue is with the handling of multi-destination
   packet distribution trees. Another issue is with TRILL switch
   nicknames.  There have been two proposed approaches.  One approach,
   which we refer to as the "unique nickname" approach, gives unique
   nicknames to all the TRILL switches in the multilevel campus, either
   by having the Level-1/Level-2 border TRILL switches advertise which
   nicknames are not available for assignment in the area, or by
   partitioning the 16-bit nickname into an "area" field and a "nickname
   inside the area" field.  The other approach, which we refer to as the
   "aggregated nickname" approach, involves hiding the nicknames within
   areas, allowing nicknames to be reused in different areas, by having
   the border TRILL switches rewrite the nickname fields when entering
   or leaving an area. Each of those approaches has advantages and
   disadvantages.

   This informational document suggests allowing a choice of approach in
   each area. This allows the simplicity of the unique nickname approach
   in installations in which there is no danger of running out of
   nicknames and allows the complexity of hiding the nicknames in an
   area to be phased into larger installations on a per-area basis.

Working Group Summary

WG has worked on these solutions for 2+ years.  
  The WG consensus had no objections, and support of all key players with comments. 

  WG LC:
  https://www.ietf.org/mail-archive/web/trill/current/msg07079.html

Document Quality

Protocol extension has no implementation of this code. 
 Huawei plans to implement this function. 

Personnel

  Document shepherd: Susan Hares
  Responsible AD: Alia Atlas