Subject: [Gen-art] GenART review of draft-ietf-mpls-p2mp-oam-reqs-01.txt

From: [email-masked]
Date: Tue, 15 Aug 2006 19:49:24 -0400

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.

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.

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.

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"

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-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 17 Aug 2006 01:10:57 +0100

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-masked]>
>

> 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.

> in this draft - please remove it from this section.

OK

> 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?

> "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?

---

From: [email-masked]
Date: Thu, 17 Aug 2006 14:24:11 -0400

Adrian,

Some more inline comments, only on things that are still open, --David

> 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.
 
> 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