Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension
draft-ietf-trill-channel-tunnel-11

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: draft-ietf-trill-channel-tunnel@ietf.org, akatlas@gmail.com, trill-chairs@ietf.org, trill@ietf.org, "The IESG" <iesg@ietf.org>, shares@ndzh.com, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'TRILL: RBridge Channel Header Extension' to Proposed Standard (draft-ietf-trill-channel-tunnel-11.txt)

The IESG has approved the following document:
- 'TRILL: RBridge Channel Header Extension'
  (draft-ietf-trill-channel-tunnel-11.txt) as Proposed Standard

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-channel-tunnel/

Ballot Text

Technical Summary

   The IETF TRILL (Transparent Interconnection of Lots of Links)
   protocol includes an optional mechanism, called RBridge Channel, that
   is specified in RFC 7178, for the transmission of typed messages
   between TRILL switches in the same campus and between TRILL switches
   and end stations on the same link. This document specifies two
   optional extensions to the RBridge Channel protocol: (1) A standard
   method to tunnel a variety of payload types by encapsulating them in
   an RBridge Channel message; and (2) A method to support security
   facilities for RBridge Channel messages. This document updates RFC
   7178.

Working Group Summary

 WG Issue is part of the directory services work which 
 has received discussion over 2 years.  The WG has strong 
 consensus after this lengthy discussion on the problem
 and the set of drafts for the solution.

Document Quality

About document reviews:
   c-1) shepherd review thread: 
   https://mailarchive.ietf.org/arch/msg/trill/NZ8vNTic0FwG3UUc-x1Oj7QKlew
  Comments were satisfied with the -06 of this draft as shown: 
  Authors response to shepherd: 
  https://mailarchive.ietf.org/arch/msg/trill/RnbMobG6zI1aV8ViTKbOA1QM8q8
 Shepherd's ok:
https://mailarchive.ietf.org/arch/msg/trill/-_1uigPg0-yZ7wXEjFfZpI45dQU

   c-1) routing-QA review:  Waited from 
   c-2) OPS-DIR review: OPS-DIR early review requested due to tunnel, no takers. 
   c-3) IANA QA Review:  IANA pre-review indicated OK.  
   C-4) SAAG QA Review: Completed 


About implementations:

 Directory service mechanism are currently implemented as proprietary 
  fashions by every vendor that does some variant of TRILL (cisco, brocade, Huawei
  and others).  Until we get a full standard solution approved, the 
  existing vendors with "early TRILL" implementations have little reason
  to switch. 

  Huawei is planning implementations. Potentially Brocade and Cisco
  could switch to these mechanisms, but unless IETF standards are out
  as a set - this may not occur.  

Personnel
document shepherd: Susan Hares 
Responsible AD: Alia Atlas

RFC Editor Note