Document Action: 'OAM Requirements for Point-to-Multipoint MPLS Networks' to Informational RFC

[The IESG <iesg-secretary at ietf.org>]

The IESG has approved the following document:

- 'OAM Requirements for Point-to-Multipoint MPLS Networks '
   <draft-ietf-mpls-p2mp-oam-reqs-01.txt> as an Informational RFC

This document is the product of the Multiprotocol Label Switching Working 
Group. 

The IESG contact persons are Ross Callon and Bill Fenner.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-oam-reqs-01.txt

Technical Summary
 
This informational document describes requirements for data plane
operations andmanagement for P2MP MPLS LSPs. These requirements apply to
all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs
and multicast LSPs.
 
Working Group Summary
 
The chairs have not answered this question after multiple requests. The
authors report that there was no dissent, and that there was review from
multiple experts.
 
Protocol Quality
 
Ross Callon has reviewed this for the IESG.

Note to RFC Editor
 
There are a few Nits identified during the Gen-ART review that should be
corrected prior to publication. I have copied these here (comments  by
<Black_David at emc.com>):

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


_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce