[trill] AD review of draft-ietf-trill-centralized-replication-08

Alia Atlas <akatlas@gmail.com> Wed, 14 June 2017 20:52 UTC

Return-Path: <akatlas@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 2889312943D; Wed, 14 Jun 2017 13:52:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id E3wHuN7_Rs-w; Wed, 14 Jun 2017 13:52:36 -0700 (PDT)
Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1469E126CC4; Wed, 14 Jun 2017 13:52:33 -0700 (PDT)
Received: by mail-wr0-x22b.google.com with SMTP id r103so14872726wrb.0; Wed, 14 Jun 2017 13:52:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=36iIzwArJnsEq7rkVVuQh7sU3M3G6qFCR6yjHWc6Y7Y=; b=YVYhP4Y4RCt2dMR3mfUqlfuLvRWn6gkcAeg0AkxIaTApxP5P5F/T5ciOPvGQAzUN1s tCSi654vabgX2qzt17x+bN0OttnrwgFZJiWq7Cxh7ggSIqrkV0SGPAqcB5rzqYTs4Raj Ga99KfZzuCjf1Vmc/0OFafXAZeVCiJoDteEKBIo5aZpUxLi1dxR+LLDOgCdrDuaP5JCO SVLNvuktH0tRpqbj0dxuV5KUjvKwIEq5DUzf+T5gcXL2VNRQAJjCWZNXQ0JB5wAQ8MB/ tnOkPy8nwEbF08d24n1DPKD0cPgrkFMTfTtE/PbAWQpNdlC4Zr1k0ND+3VdeBjjZ0yCd Xf5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=36iIzwArJnsEq7rkVVuQh7sU3M3G6qFCR6yjHWc6Y7Y=; b=n3qAdt/rnA0ieqWlzyykcHxeIZyYW8bjNMrWleimEc0V1Jn5y0j3N9EGahn9/cHWll ysklsLJwx0MKnsYuoWhJVxVo69f/mFQsBmGoZoBhg1VGa0PsW83MFzATgxx1/m/epAZ3 XMBfDldblb0dbxtvLuTe9vZjVkQnn7EpE+yOJg5dk5Bd4uK0zTZ3hPrlxhEbB54/4eOl cJBA+S8yUfSYY7po9BvzlUH1IRsT6ha6Aop69KlttWN9uQUtot4CzIbO+kc9B8UwmM3p KXTAGcOUiAiBRbmjbbMvXvXO35T7FtXAjwsfIT5vfWyY4rAb3595/V/k9Zh3WuiQ6nHb k9GQ==
X-Gm-Message-State: AKS2vOyp3Rmz1ZuLbRQqP/t/o5DCuth1fpOKEt5aJqBh/wZDnU5oHHu1 F2VDtlOplh7JyTaLWE7SAJWSq08n555P/UI=
X-Received: by with SMTP id h198mr1273740wmg.40.1497473551294; Wed, 14 Jun 2017 13:52:31 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 14 Jun 2017 13:52:30 -0700 (PDT)
From: Alia Atlas <akatlas@gmail.com>
Date: Wed, 14 Jun 2017 16:52:30 -0400
Message-ID: <CAG4d1rdVDFv57eRvzfXKeUQaixjaLMh-QszBJjfWmhbubdXA4Q@mail.gmail.com>
To: trill@ietf.org, draft-ietf-trill-centralized-replication@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c19319815e6b80551f1bbc1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/AEW2s0f3dEVHKe9pYDdbb54c9I0>
Subject: [trill] AD review of draft-ietf-trill-centralized-replication-08
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
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: <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: Wed, 14 Jun 2017 20:52:38 -0000

As is customary, I have done my AD review
of draft-ietf-trill-centralized-replication-08. First, I would like to
thank the authors - Weiguo Hao, Yizhou Li, Muhammad Durrani, Sujay Gupta,
and Andrew Qu - for their work on this document.

I do have a few concerns that need to be addressed before the document can
proceed to IETF Last Call.  If the authors can address them very rapidly
(this week), then I have time for an IETF Last Call and putting the draft
on the IESG Telechat of July 6.

1) In Sec 3, it says"In this case, the RPF calculation on each RBridge
should use the centralized node as the ingress RBridge instead of the real
ingress virtual RBridge to perform the calculation."
In Sec 7, it says"The egress nickname in the multi-destination TRILL Header
is the nick5 and the ingress nickname is still P-nick."

>From scanning RFC6325, I am reminded that the egress nickname indicates the
destination tree.   I don't see clearly specified here how the RBridge
determines which RPF calculation to use for a particular frame....

In Sec 11,"A C-nickname is a specialized pseudo-nickname for which transit
RBridges perform a different RPF check algorithm for TRILL data packets
with the C-nickname in the ingress nickname field."

If I follow the logic here, an RBridge is intended to install a different
RPF interface-set for each C-nickname - but what that RPF interface-set is
will also be dependent upon the egress nickname specified??     Does this
turn the look-up from a simple ingress nickname (16 bit) to interface-set
into a something more complicated?
I guess it could be a recursive lookup, where if the ingress nickname is a
C-nickname, then the RPF interface-set is looked up again from the egress
name instead?

If I am correct, then this is a definite change in fast-path forwarding
behavior and should be described extremely clearly - which it is not.

I don't think that Sec 8 helps in guessing which distribution tree will be

2) In Sec 10:"In this case, an edge group using CMT [RFC7783] MUST NOT set
the C-
   nickname flag on the pseudo-nickname it is using."
Given that an implementation support RFC7783 may not support this document,
clarify in the document how it is that an implementation conformant to
RFC7783 is guaranteed to not set the C-nickname flag.

3) Sec 11:" When active-active edge RBridges use centralized replication to
   nickname and the C-nickname is used as ingress nickname in the TRILL
   header for the unicast TRILL encapsulation of BUM traffic."

I have no idea what this sentence fragment means.

4) Sec 12: There is a claim of no new security concerns, but this basically
gives a device the ability to advertise an R-nickname and get all/some of
the BUM traffic unicast to it - where that device could modify, block, or
respond to the BUM traffic and the rest of the campus - except for the
local neighbors of ingress RBridge would have no idea this was happening!
I think that some discussion of exactly what security mechanisms for IS-IS
ensure that a device injecting an R-nickname is trusted would be helpful as
well as articulating the potential impact.