Hi Wes, Thanks for the comments.
On 19 Jun 2012, at 16:05, George, Wes wrote: > I've read this draft and I think it is useful and ready to proceed. > Two minor comments: > > In section 4, it may be useful to specifically note the need for a flag, > trap, or other notification method (to the user, rather than to the neighbor) > to identify when BGP is in the process of recovering RIB consistency, > including which routes are considered inconsistent (if this info is > available). While section 6 discusses the need for more information about the > state of BGP when it is recovering from these errors, I saw no reference to > this specific item. Since this is likely to be a transient state, it is also > helpful to log this information to aid in root cause analysis of transient > problems. This sounds like a good addition -- I'll add a statement regarding this into the -05 version of the draft. > Also, there are a lot of uses of RFC2119 words in ways that could be > interpreted as normative despite the lack of a reference to 2119. It may be > useful to either go ahead and make them so (all caps, include RFC2119 > boilerplate) or to consider alternate words to avoid confusion. While this is > an informational document and not a protocol specification, there are a lot > of specific requirements of what we are expecting changes to the > implementation to do and not do such that normative words would likely be > helpful both to implementers and to those who may follow this draft with one > to make protocol changes to address the requirements set forth. I'd be interested in further comments on this -- the intention of the document originally was to frame the problem space, as well as put forward requirements for solutions. If there is value in putting forward these requirements with 2119 wording, then I'll go ahead and do so. Kind regards, r. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
