Re: [trill] AD review of draft-ietf-trill-pseudonode-nickname-04

[Mingui Zhang <[e-mail]>]

Hi Alia,

Please see comments inline with [mingui].


From: trill [mailto:[e-mail]] On Behalf Of Alia Atlas
Sent: Friday, July 31, 2015 6:30 AM
To: [e-mail]; [e-mail]; Don Eastlake
Subject: [trill] AD review of draft-ietf-trill-pseudonode-nickname-04

First, let me thank Hongjun, Tissa, Radia, Mingui, and Yizhou, the authors of this fine draft, for their hard work in producing a document that is easy to read and very detailed.

As is customary, I've done my AD review of this draft before requesting IETF Last Call.  I do have a few questions and clarifications which I will describe.

I intend to review the other two associated trill drafts tomorrow and progress all 3 to an IETF Last Call with a target of getting on the Aug 20 IESG telechat.  If that telechat gets too full, they might need to move to two weeks later.

As we finally push through on this process, having very responsive authors helps immensely in getting drafts through the process.

Here are the details of my review:

Minor concerns:

1) On p. 15 & 16: I'm a bit confused because on p. 15, it says "The basic
idea of DF is to elect one RBridge per VLAN from an RBv to egress
multi-destination TRILL Data traffic and replicate locally-received
multi-destination native frames to the CEs served by the RBv."  but
then on p. 16 in Step 4 part 1), it says: "RBv ports associated with
the same pseudo-nickname as that of the incoming port, no matter
whether RBi is the DF for the frame's VLAN on the outgoing ports
except that the frame MUST NOT be replicated back to the incoming
port".  This seems to be contradictory.

[mingui] Let me explain the logic. If the RBridge in a RBv group receives a BUM packet from a locally connected CE.  Other CEs will receive the packet replicated by the DF only. Other RBridges will refrain from replicating.
Having said that, it is also important that the DF never replicates the BUM packet back to the incoming port (Say CE1 sends the BUM packet to the DF RB1 via port 1, then RB1 does not send the replicated BUM packet back to CE1 via port 1.)

Moreover, if one say CE1,
CE2, and CE3 all in the same RBv, when CE1 sends a packet to RB2 and
RB1 is the DF for the particularly VLAN, then wouldn't RB2 forward the
packet to CE1 and CE2 while RB1 would also do so as the DF?

[mingui] As explained above, RB2 will refrain from replicating since it is not the DF.

Could you
please clarify what is causing the inconsistency and problem?  Maybe
the text in 6.1 on p. 18 helps describe that there are actually two
cases to the text on p. 16?

[mingui] Yes, I agree.

2) On p.23 in Sec 9.1: There is no way of identifying what the type of
the LAALP ID is.  Assuming it is a number and meaning doesn't matter,
it would be really good to clarify that.

[mingui] Agree.

3) In Sec 9.2: How can an LAALP ID be withdrawn from PN-RBv
APPsub-TLV?  Could you please describe that sequence?

[mingui] I think, if RBx needs to just withdraw one LAALP ID, it will refresh the previous announced LSP by omitting that LAALP ID from the LAALP ID list in the PN-RBv APPsub-TLV.

Thanks,
Mingui


Thanks,
Alia