Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt

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

Hi Donald,

This looks reasonable, and in particular the remaining Recommendations
section (section 6) in the just-posted -04 version is fine with me.

Thank you for dealing with these comments.

Thanks,
--David

> -----Original Message-----
> From: Donald Eastlake [mailto:[e-mail]]
> Sent: Monday, February 25, 2013 12:01 PM
> To: Black, David
> Cc: [e-mail]
> Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt
> 
> Hi David,
> 
> Thanks for pointing out your earlier review and comments which were
> partially responded to at the time.
> 
> I understand that you comments were on the -02 version. When I say
> below something was done, I'm referring to the -03 version and when I
> just say OK or indicate something will be done, I am referring to the
> to be posted -04 version.
> 
> On Sat, Nov 24, 2012 at 3:28 PM, Black, David <[e-mail]>
> wrote:
> > Hi Linda,
> >
> > Here are some (somewhat tardy) comments on this WG Last Call.
> >
> > (1) As noted by some of the others who commented, more functionality
> > details would be good to add, especially on mixing of the push and
> > pull models in Section 5.  Cache consistency needs to be covered,
> > at least its invalidation portion, as relying solely on aging out
> > entries can black-hole traffic that uses a stale entry that hasn't
> > aged out yet.
> 
> Functional detail is to be covered in
> draft-dunbar-trill-scheme-for-directory-assist a new version of which
> is about to be posted. The framework document is very high level and
> it's primary purpose was to provide a means for the WG to indicate its
> approval of pursuing this direction. However, we will put in a bit
> more concerning cache consistency.
> 
> > (2) I also agree with Erik's earlier comment about not understanding
> > why Appointed Forwarders are in this draft.  If use of a directory
> > can relax Appointed Forwarder restrictions without causing problems
> > (e.g., loops), that needs to be explained somewhere, probably in
> > Section 4.  Otherwise, Appointed Forwarders should not be discussed.
> 
> References to Appointed Forwarders will be removed.
> 
> > (3) On the comment about capitalizing MUST, SHOULD and MAY, the
> > applicable RFC is RFC 2119, but those terms are not ordinarily used
> > in requirements documents.  An explanation that these keywords
> > express requirements on protocol development should be provided in
> > order to use the upper case versions of these keywords.
> 
> Reference to RFC 2119 and capitalized implementation requirement words
> were eliminated.
> 
> > Here are some more detailed comments:
> >
> > Abstract:
> >    Edge RBridges currently learn the mapping between MAC addresses and
> >    their egress RBridges by observing the data packets traversed
> >    through.
> >
> > Change to: ... by observing traffic that traverses the RBridge.
> 
> Actually, I don't particularly like "traverses". It sound like
> learning from transit frames, which TRILL switches do not do, although
> the fact that it mentiones "Edge RBridges" helps. I think "...by
> observing traffic they ingress or egress..." would be better.
> 
> > Section 1, 1st paragraph:
> >
> >                 (This ''blocked'' state
> >    has no effect of TRILL Data or IS-IS frames, which can still be sent
> >    and received. It only affects native frames.)
> >
> > "of TRILL data" -> "on TRILL Data" in second line above.
> 
> That wording has been removed.
> 
> > In item 2 in the list, I'd change "usually" to "often":
> >    2. Topology is usually based on racks and rows.
> 
> OK.
> 
> > In item 3 in the list, explain that server reload can change the MAC
> > address and why that change may be needed or desirable, because
> > Section 4 appears to assert that the MAC address can change.  If
> > that wasn't intended, this text in Section 4 needs attention for
> > physical servers (it's ok for VMs):
> >
> >    When a VM is moved to a new
> >    location or a server is loaded with a new application with different
> >    IP/MAC addresses, it is more likely that the DA of data packets sent
> >    out from those VMs are unknown to their attached edge RBridges.
> 
> OK.
> 
> > Item 4 should follow up on the mention of subnets in item 3 and
> > observe that multiple subnets on the same port at the same time is
> > common for server virtualization and the change rate is higher than
> > for physical servers.
> 
> OK.
> 
> > In the definition of "Bridge", change "draft" to "document".
> 
> There are a number of occurrences of "draft" which should probably be
> changed because it will not be a draft when it is published as an RFC.
> 
> > Section 3, p.6, first bullet - change both instances of "RB1" to
> > "an RBridge" as there's no RB1 in figure 1.
> 
> OK.
> 
> > The last bullet in Section 3.1 is a bit sloppy about its use of the
> > word "entries".  It needs to explain exactly what is in an "entry" -
> > it might be possible to do this in an introduction by stating that
> > the presence of an entry (and list what it contains) avoids flooding
> > of inbound frames that match the entry.
> 
> The wording will be improved.
> 
> > Section 3.2, Scenario #1 - The use of the word "uplink" is confusing,
> > overly constraining and not necessary.  The important concept is how
> > many ToR switches are in each rack.  It's quite feasible for a server
> > or switch in a rack to have multiple uplinks to the same ToR (e.g.,
> > when the links are 1 Gigabit Ethernet).
> 
> OK.
> 
> > Section 4, first sentence:
> > OLD
> >    In data center environment, applications placement to servers,
> >    racks, and rows is orchestrated by Server (or VM) Management
> >    System(s).
> > NEW
> >    In a data center environment, the assignment of applications
> >    to servers, including rack and row selection, is orchestrated
> >    by Server (or VM) Management System(s).
> > END
> 
> That seems like an improvement in wording.
> 
> > I'd suggest deleting Section 6 (Conclusion and Recommendations), as
> > it's important for considering what the WG will do, but may not have
> > much value in a published RFC.
> 
> Since the point of the adoption of this document was the the TRILL WG
> wishes to pursue directory assistence, I think that the recommendation
> part should stay.
> 
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]
> 
> > Thanks,
> > --David
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Erik
> >> Nordmark
> >> Sent: Wednesday, November 14, 2012 4:13 PM
> >> To: [e-mail]
> >> Subject: Re: [trill] WG Last Call:
> >>    draft-ietf-trill-directory-framework-01.txt
> >>
> >> We would really like to she some more explicit indications from WG
> >> participants that they have read this document and agree with it.
> >>
> >> Please include any substantial as well as editorial improvements that
> >> result from reviewing the document.
> >>
> >>     Erik
> >>
> >> On 10/25/12 3:55 PM, Donald Eastlake wrote:
> >> > This message begins a TRILL WG two week Last Call on the
> >> > draft-ietf-trill-directory-framework draft.
> >> >
> >> > Thanks,
> >> > Donald
> >> > =============================
> >> >   Donald E. Eastlake 3rd   [phone] (cell)
> >> >   155 Beaver Street, Milford, MA 01757 USA
> >> >   [e-mail]