Adrian, Some more inline comments, only on things that are still open, --David
> > Section 4.1 > > > > The discussion of limits on proactive OAM loading should probably > > explicitly say that reactive OAM (dealing with something that has gone > > wrong) may violate these limits (i.e., cause visible traffic > > degradation) if that's necessary or useful to try to fix whatever has > > gone wrong. > > Can you explain your point please? When you say "may" do you mean that in > your opinion reactive OAM is allowed to cause LSRs to be overwhelmed. I > can't honestly say that would be a good idea because an overwhelmed LSR will > not be able to do anything constructive. > > I am also confused as to why you suggest placing this text in section 4.1. > This section is about detecting defects. That is, it is about proactive OAM > only. Section 4.2 is about diagnosis. We could, I suppose, add a similar > requirement to section 4.2 (that is, diagnostic OAM similarly MUST NOT > overwhelm an LSR). Would that be OK? The concern I have is that that the draft defines "overwhelmed" to include any condition in which the advertised rate or data rate cannot be sustained. That puts proactive OAM traffic into a fairly tight box, which is fine - if nothing is broken, interference with real traffic ought to be avoided. OTOH, when something has gone wrong, the advertised rate or data rate may already be history, and a requirement not to degrade it further may be ill-advised (e.g., that could prohibit use of LSP Ping, which would probably be wrong). So, part of my concern is that **if** "overwhelmed" is defined as inability to support the advertised rate or data rate **then** I don't agree that "an overwhelmed LSR will not be able to do anything constructive." The LSR and/or affected interface(s) may be able to function in a degraded mode of some sort. With that as context, Section 4.2 would be a fine place to say that it is ok for reactive OAM traffic to introduce further degradation in the hope of determining what is wrong and getting it fixed, but that degradation should be limited, so as not to make things significantly worse. > > Also, a wording nit: > > > > In practice, of course, the requirements in the previous paragraph > > may be overcome by careful specification of the anticipated data > > throughput of LSRs or data links, > > > > "overcome" --> "satisfied" or "met" > > The point is that the requirements are not satisfied or met by this process. > Perhaps "avoided" would be an acceptable word? In that case, the whole paragraph needs a rewrite. I think this is about providing "headroom" for proactive OAM traffic between the sum of the advertised rates and the actual (physical?) rate limit of the interface, but the current text is not clear enough (i.e., which requirements?) for me to be sure. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED] Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
