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

[Donald Eastlake <[e-mail]>]

See below

On Sun, Aug 2, 2015 at 11:45 PM, Mingui Zhang <[e-mail]> wrote:
> 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
>
> ...
>
> 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.

Probably the wording can be clarified.

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

The general requirement is that the LAALP ID identify the
active-active edge group of end stations and the LAALP for a
particular group must be unique across the TRILL campus. As far as I
know, currently the only type of value used for the LAALP ID is an
8-byte MC-LAG/DRNI ID. Perhaps the document should (1) indicate the
general requirement, (2) state that if the length is 8 it MUST be an
MC-LAG/DRNI ID, and (3) say that the type of LAALP ID value for any
other length will be specified in a future document.

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

The APPsub-TLV (which is inside a TRILL GENINFO IS-IS TLV) is link
state although it is not part of the base routing information LSP. It
is distributed in E-L1FS FS-LSPs (support for which is required by
draft-ietf-trill-rfc7180bis which is also in publication requested
state). So the contents of the APPsub-TLV can be changed or it can be
withdrawn by changing the FS-LSP fragment in which it occurs.

> Thanks,
> Mingui
>
> Thanks,
> Alia

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]