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

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

MIME-Version: 1.0
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
Precedence: list

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
used.

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,
please
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.

 Regards,
Alia

[trill] AD review of draft-ietf-trill-centralized… Alia Atlas