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

[Alia Atlas <[e-mail]>]

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]>
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]] On Behalf Of Donald Eastlake
> > Sent: Wednesday, August 12, 2015 4:39 AM
> > To: [e-mail]
> > Cc: Tissa Senevirathne; [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] (cell)
> >  155 Beaver Street, Milford, MA 01757 USA  [e-mail]
> >
> >
> > On Wed, Aug 5, 2015 at 11:07 PM, Donald Eastlake <[e-mail]>
> > wrote:
> > > 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]
> _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill
>