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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
