[Gen-art] Gen-ART review of draft-ietf-trill-directory-framework-07

["Black, David" <[e-mail]>]

The -07 version is also ready for publication as an Informational RFC

Thanks,
--David

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Black, David
> Sent: Monday, July 29, 2013 7:20 AM
> To: [e-mail]; Donald Eastlake; [e-mail]; igor@yahoo-
> inc.com; General Area Review Team
> Cc: Ted Lemon; [e-mail]; [e-mail]
> Subject: Re: [Gen-art] Gen-ART review of draft-ietf-trill-directory-framework-
> 06
> 
> The -06 version of this draft resolves all of the concerns raised by the Gen- ART
> review of the -05 version - the -06 version is ready for publication as an
> Informational RFC.
> 
> Thanks,
> --David
> 
> > -----Original Message-----
> > From: Black, David
> > Sent: Wednesday, July 17, 2013 7:54 PM
> > To: [e-mail]; Donald Eastlake; [e-mail]; igor@yahoo-
> > inc.com; General Area Review Team
> > Cc: [e-mail]; [e-mail]; Black, David; Ted Lemon
> > Subject: Gen-ART review of draft-ietf-trill-directory-framework-05
> >
> > Document: draft-ietf-trill-directory-framework-05
> > Reviewer: David L. Black
> > Review Date: July 17, 2013
> > IETF LC End Date: July 18, 2013
> >
> > Summary:
> > This draft is on the right track but has open issues, described in the review.
> >
> > This draft describes a framework for using directory servers to provide
> > address mappings (address -> destination RBridge) to TRILL Rbridges as an
> > alternative to data plane learning and use of the TRILL ESADI protocol.
> >
> > The draft's generally well written and clear.  I found a couple of minor
> > issues.
> >
> > Major issues: None.
> >
> > Minor issues:
> >
> > [1] The last bullet in Section 3.1 says:
> >
> >        - In an environment where VMs migrate, there is a higher chance
> >          of cached information becoming invalid, causing traffic to be
> >          black-holed by the ingress RBridge, that is, persistently sent
> >          to the wrong egress RBridge. If VMs do not flood gratuitous
> >          ARP/ND or VDP [802.1Qbg] messages upon arriving at new
> >          locations, the ingress nodes might not have MAC entries for the
> >          MAC of the newly arrived VMs, causing unknown address flooding.
> >
> > This is incorrect in multiple ways and should just be removed:
> >
> > - Persistent black-holing is rare in practice because all common
> > 	VM migration implementations issue the gratuitous messages.
> > - VMs don't send the gratuitous messages, hypervisors do.
> > - VDP is not flooded.  The receiver's always a bridge.
> > - At least one common VM migration implementation actually uses a gratuitous
> > 	RARP, not ARP.
> > - Flooding is done by the bridges and Rbridges, not the VMs.
> >
> > [2] There are some unfortunate notation problems in Section 5.1 that carry
> > into the following sections, based on the logical data structure:
> >
> >    [{IP, MAC/VLAN, {list of attached RBridge nicknames}, {list of
> >    interested RBridges}]
> >
> > - The first open curly brace ('{') is unmatched.
> > - Subsequent text uses [IP or MAC/VLAN], IP/MAC/VLAN and MAC&VLAN,
> > 	none of which appear in that structure.
> >
> > Nits/editorial comments:
> >
> > Section 1 - item 1 in the numbered list does not explain why it makes
> > a directory approach attractive.  This should be added, as it is
> > present for the other three items .
> >
> > Section 2 - Say that IS-IS is a routing protocol.
> > The definition of Station should say that the node or virtual node
> > is on a network.  Also, please define or explain "virtual node".
> >
> > Section 3.2 - Add the number of entries to be learned to scenario #1
> > in order to parallel the scenario # 2 discussion.
> >
> > Section 4 - remove "(distributed model)" from first paragraph,
> > as it's not explained.
> >
> > Section 5.3, top of p.13:
> >
> >    therefore, there needs to be some mechanism by which RBridges that
> >    have pulled information that has not expired can be informed when
> >    that information changes or the like.
> >
> > "or the like" is vague.  I suggest "or becomes invalid for other
> >  reasons".
> >
> > idnits 2.12.17 didn't find any nits that need attention.
> >
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Distinguished Engineer
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > [phone]             FAX: [phone]
> > [e-mail]        Mobile: [phone]
> > ----------------------------------------------------
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art