[trill] Protocol Action: 'TRILL: RBridge Channel Header Extension' to Proposed Standard (draft-ietf-trill-channel-tunnel-11.txt)

The IESG <iesg-secretary@ietf.org> Mon, 15 August 2016 17:46 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: trill@ietf.org
Delivered-To: trill@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 497E512D1BD; Mon, 15 Aug 2016 10:46:10 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.29.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147128317027.31650.6690362244190568531.idtracker@ietfa.amsl.com>
Date: Mon, 15 Aug 2016 10:46:10 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/wOuFpYJNCoC8fybPxS8LZV7q0jA>
Cc: draft-ietf-trill-channel-tunnel@ietf.org, akatlas@gmail.com, trill-chairs@ietf.org, The IESG <iesg@ietf.org>, trill@ietf.org, shares@ndzh.com, rfc-editor@rfc-editor.org
Subject: [trill] Protocol Action: 'TRILL: RBridge Channel Header Extension' to Proposed Standard (draft-ietf-trill-channel-tunnel-11.txt)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Aug 2016 17:46:10 -0000

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/





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