David: Thanks for your review. See in-line for responses.
MPLS WG: FYI
Ross/Bill: Please let me know if you would like a new revision at this stage
Thanks,
Adrian
----- Original Message -----
From: <[EMAIL PROTECTED]>
I am the assigned Gen-ART reviewer for
draft-ietf-mpls-p2mp-oam-reqs-01.txt.
For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
This draft is basically ready for publication, but has nits
that should be fixed before publication.
Section 2.1
This requirements draft uses RFC 2119 terminology (MUST, SHOULD, etc.).
In addition to incorporation of the RFC 2119 boilerplate (already done),
please explain that these requirements are being stated as requirements
of OAM mechanism and protocol *development*, as opposed to the usual
application of RFC 2119 requirements to an actual protocol, as this
draft does not specify any protocol.
OK. Will add the following text to section 2.1
This use of RFC 2119 terminology is made to clarify the requirements
in this document and not to express specific protocol actions or
behaviors.
Section 2.3
OAM: Operations and Management
OA&M: Operations, Administration and Maintenance.
That's an invitation for confusion. The OA&M acronym is not used
in this draft - please remove it from this section.
OK
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?
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?
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
