[trill] ESADI draft change suggestion

Sujay Gupta <sujay.ietf@gmail.com> Mon, 23 July 2012 01:34 UTC

Return-Path: <sujay.ietf@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BF06321F864C for <trill@ietfa.amsl.com>; Sun, 22 Jul 2012 18:34:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id XPM6uWHt2BPL for <trill@ietfa.amsl.com>; Sun, 22 Jul 2012 18:34:10 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 4128921F8647 for <trill@ietf.org>; Sun, 22 Jul 2012 18:34:07 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so10288703pbc.31 for <trill@ietf.org>; Sun, 22 Jul 2012 18:34:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=J46S4uXHqViPLxl8OkggCMKYMX0+BoDw2WnPoMNf8tk=; b=TEZkL/EsrYEmlFDnHIL5MK/82Gk7bW9AKUcVAswgP0QLukOJCK1W3s900eJ0I9b/LW bigDiQPnYXVugmjcGShZ4AX1tw+aV2v98dgJn/RmV7iCnRdrTJTquAKbfnGnOqeNI5kP N6uKs/pP/75AxIejXuspQCRYnkjkEvBI8UGw7jIN355/QiLoT01T8KNUkSNF3n0QqpZA cHMhs7iXY1FDC87O2916ezMB/inJFZNQclUAtOPa2lkuL74jyc4Yhv7DjQyZvtS6d/bt u+tLGnRhTWlYlJpaXWLqDxmBEcDgqmHI/Up6QYN8KgHB3Jqmjh4a9OuijZ4qZMDeCUae hZvA==
Received: by with SMTP id qn3mr30968678pbc.135.1343007247074; Sun, 22 Jul 2012 18:34:07 -0700 (PDT)
Received: from [] ([]) by mx.google.com with ESMTPS id ph1sm8853364pbb.45.2012. (version=SSLv3 cipher=OTHER); Sun, 22 Jul 2012 18:34:05 -0700 (PDT)
Message-ID: <500CAA09.5070405@gmail.com>
Date: Mon, 23 Jul 2012 07:04:01 +0530
From: Sujay Gupta <sujay.ietf@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: trill@ietf.org
References: <CAF4+nEFi=oTvtVJYczV8vS6+ni4UXS0CBSNTATk7aegXtbe4NQ@mail.gmail.com>
In-Reply-To: <CAF4+nEFi=oTvtVJYczV8vS6+ni4UXS0CBSNTATk7aegXtbe4NQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------060808050000040506040300"
Subject: [trill] ESADI draft change suggestion
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: <http://www.ietf.org/mail-archive/web/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, 23 Jul 2012 01:34:12 -0000



The ESADI protocol objectives as stated in the draft-04, IMO needs added 
Section 1: "Introduction"

    protocol's potential advantages over data plane learning include the

    1. Security advantages:..
    2. Fast update advantages:..

w.r.t to Security advantages, albeit ESADI can make a authenticated entries an insecure ESADI increases
the security vulnerability then without it. My recommendation is to recommend a SHOULD clause to implement
security features. A secured deployment of TRILL may choose to live with a unsecured ESADI ( & therefore
possibly a more efficient/lighter ESADI); whilst a TRILL plane bridging 3rd party aggregation and application
layers may choose for trusted/secured model.


This is w.r.t to learning of ESADI entries and timing them out. As per RFC 6325, the entries are expected
to be removed only by the originating RBridge.
Section 4.8.3
"The situation is different for end-station address information acquired via the TRILL ESADI protocol.
It is up to the originating RBridge to decide when to remove such information from its ESADI LSPs
(or up to ESADI protocol timeouts if the originating RBridge becomes inaccessible)."
  For robust behavior it would be better to timeout the entries without depending on ESADI, the reason
is a (wrong)ESADI directed forwarding can cause persistent traffic loss, unlike a best effort flood everywhere
situation. Therefore my recommendation is the specs should not 'mandate' the timing out behavior.

Best Regards,