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

[Mingui Zhang <[e-mail]>]

Hi Alia,

Sorry for the delay.
I agree that Donald has cleared out the inconsistency. The updated version has been uploaded.

Thanks,
Mingui

From: Alia Atlas [mailto:[e-mail]]
Sent: Monday, August 17, 2015 11:58 PM
To: Mingui Zhang
Cc: Donald Eastlake; [e-mail]; Tissa Senevirathne; [e-mail]
Subject: Re: [trill] AD review of draft-ietf-trill-pseudonode-nickname-04

Hi Mingui,

I need the updated version ASAP.  If I don't see it today, I will have to put off reviewing the draft on the IESG telechat for another 2 weeks.

Donald's suggested text does clear up my concern about the inconsistency around the non-DF behavior.

Thanks,
Alia

On Wed, Aug 12, 2015 at 9:55 PM, Mingui Zhang <[e-mail]<mailto:[e-mail]>> wrote:
Hi Donald,

Appreciate the review. The suggested changes are fine. Authors will incorporate them and send out the updated draft for your review. If it will be OK. The new version will be uploaded by tomorrow.

Thanks,
Mingui

> -----Original Message-----
> From: trill [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Donald Eastlake
> Sent: Wednesday, August 12, 2015 4:39 AM
> To: [e-mail]<mailto:[e-mail]>
> Cc: Tissa Senevirathne; [e-mail]<mailto:[e-mail]>
> Subject: Re: [trill] AD review of draft-ietf-trill-pseudonode-nickname-04
>
> Hi,
>
> I believe the mark ups in the attached resolve the AD comments on
> draft-ietf-trill-pseudonode-nickname and also update some author info.
> Could the authors please incorporate changes along these lines and post a new
> draft or, alternatively, point out my errors and propose different changes.
>
> Thanks,
> Donald (document Shepherd)
> =============================
>  Donald E. Eastlake 3rd   [phone]<tel:%2B1-508-333-2270> (cell)
>  155 Beaver Street, Milford, MA 01757 USA  [e-mail]<mailto:[e-mail]>
>
>
> On Wed, Aug 5, 2015 at 11:07 PM, Donald Eastlake <[e-mail]<mailto:[e-mail]>>
> wrote:
> > See below
> >
> > On Sun, Aug 2, 2015 at 11:45 PM, Mingui Zhang <[e-mail]<mailto:[e-mail]>>
> wrote:
> >> Hi Alia,
> >>
> >> Please see comments inline with [mingui].
> >>
> >> From: trill [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Alia Atlas
> >> Sent: Friday, July 31, 2015 6:30 AM
> >> To: [e-mail]<mailto:[e-mail]>;
> >> [e-mail]<mailto:[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]<mailto:[e-mail]>
_______________________________________________
trill mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/trill