Subject: Protocol Action: 'TRILL: ARP/ND Optimization' to Proposed Standard (draft-ietf-trill-arp-optimization-09.txt)

From: The IESG <[email-masked]>
Date: Sun, 12 Nov 2017 18:37:18 -0800

The IESG has approved the following document:
- 'TRILL: ARP/ND Optimization'
  (draft-ietf-trill-arp-optimization-09.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-arp-optimization/

Technical Summary

This document describes mechanisms to optimize the ARP (Address
   Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL
   campus. Such optimization reduces packet flooding over a TRILL
   campus.

This WG Draft is part of a directory service solution 
that has been discussed for 3 years.  Consensus 
is strong on the complete solution. 
This was sent back to the WG to resolve Discusses about
SEND & the draft is now believed to do that.

Document Quality
a) Are there existing implementations of the protocol? 

 No, and this draft is part of a 4 draft directory service dealing
 with directory services.  The four drafts are: 
 draft-ietf-trill-directory-assist-mechanisms () - describes the push/pull
 draft-ietf-trill-channel-tunnel-05 - secure tunnel for directory push
 draft-ietf-trill-ia-appsubtlv-05 - reporting of addresses for TRILL interfaces
    in ISIS application sub-TLV (reduces/replaces need for ARP/ND )
 draft-ietf-trill-arp-optimization - mechanism to optimize ARP and ND traffic
    on TRILL campus 
 
 b) Have a significant number of vendors indicated their plan to 
  implement the specification?
  
  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.   

 Shepherd review: 
https://mailarchive.ietf.org/arch/msg/trill/SVmP0QNwY3UaVhbjkweULl1ZxLE
Revision -01 
https://mailarchive.ietf.org/arch/msg/i-d-announce/2hbdxmCfRW34_AgGaBC0mGGJMF8
(note: no change to RFC2119 text, Shepherd is checking on the right RFC2199 text). 
  
Routing QA review: Eric Gray
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html

Personnel

AD: Alia Atlas
Document Shepherd: Susan Hares