Network Management Framework for MPLS-based Transport Networks
draft-ietf-mpls-tp-nm-framework-05

[Ballot comment]
Section 7.1:

For IPv6, the
  reported Next-Hop MTU could be as low as 1280 octets (the minimum
  IPv6 MTU) [RFC2460].

Actually the reported MTU can be lower than 1280. The proper response is to send if I understand RFC 2460 is to send a <= 1280 bytes packet with fragmentation header.

From section 5 of RFC 2460:

  In response to an IPv6 packet that is sent to an IPv4 destination
  (i.e., a packet that undergoes translation from IPv6 to IPv4), the
  originating IPv6 node may receive an ICMP Packet Too Big message
  reporting a Next-Hop MTU less than 1280.  In that case, the IPv6 node
  is not required to reduce the size of subsequent packets to less than
  1280, but must include a Fragment header in those packets so that the
  IPv6-to-IPv4 translating router can obtain a suitable Identification
  value to use in resulting IPv4 fragments.  Note that this means the
  payload may have to be reduced to 1232 octets (1280 minus 40 for the
  IPv6 header and 8 for the Fragment header), and smaller still if
  additional extension headers are used.

[Ballot discuss]
This discuss is a placeholder to ensure that some enhancements to the
security considerations (identifed based on the secidr review) are not forgotten.
The following addition to the RFC Editor Note would clear this discuss.

In Section 8:

OLD
  Provisions to any of the network mechanisms designed to satisfy the
  requirements described herein need to prevent their unauthorized use
  and provide a means for an operator to prevent denial of service
  attacks if those network mechanisms are used in such an attack.

  Solutions need to provide mechanisms to prevent private information
  from being accessed by unauthorized eavesdropping, or being directly
  obtained by an unauthenticated network element, system or user.
NEW
  The ability for the authorized network operator to access EMF interfaces
  (section 2.3) when needed is critical to proper operation.  Therefore
  the EMF interfaces need to be protected from denial of service conditions
  or attack. The EMF Interfaces that use or access private information
  should be protected from eavesdropping or being accessed by unauthorized
  network elements, systems, or users.

[Ballot discuss]
I have reviewed one of the previous versions of this document and provided my comments to the WG. Since then I see quite radical changes which mostly improved the document, but there are a few aspects left to clarify and possibly correct before approving it.

1. I was expecting to find some text describing the relationship between the management framework and the OAM framework. How are for example OAM services configured by management. How can OAM messages be used to fill in status or performance information? If such information is available in another MPLS-TP document it should be referenced here.

2. I find the performance management section changed to less than minimum and missing important information. I am confused by the definition of pro-active management - does this mean management performed by synthetic traffic generated for PM purposes? If this is ITU-T terminology I would like to see a reference. If we are talking about the need to limit reporting information, then the method of thresholding performance management objects (e.g. counters) and sending alerts in cases of exceptions is well known and deployed in IETF standards (see RMON and RMON-2) - I think that it should be mentioned. Also, in the last exchange with Eric Gray hementioned adding a statement to the effect that an MPLS-TP NE MUST support collection of loss and delay measurement data. I do not see this in the current version.

3. In the Security Considerations section the issue of authorizing access to the management information does not apply only to protect against eavesdropping, but also or especially to defend against mis-configuration or mal-configuration. Also, the reference to Section 4.3 of the Security Framework for MPLS and GMPLS Networks refers to OAM traffic but not to management traffic. If that analysis and the security practices apply also to management traffic this needs to be said explicitly.

[Ballot comment]
The Gen-ART Review by Pete McCann on 2010-02-05 raises two points
  that should be considered:

  Section 2.2 seems like a lot of complexity (and acronyms) just to
  talk about the internal architecture of one box, and to define
  interfaces that won't ever be standardized.

  In one place in section 2.2, EMF is expanded to "Element Management
  Function."  In the Terminology and elsewhere, this is "Equipment
  Management Function."

The MPLS WG requests that:
  MPLS-TP Network Management Framework
  draft-ietf-mpls-tp-nm-framework-03

is published as an informational RFC with IETF consensus.

Note that this document though it is an informational framework
document for reasons that have to do with how the ITU-T are
allowed, by there processes and rules, to reference informational
RFCs it has to go through an IETF last call and be approved as an
IETF consensus document.

> (1.a) Who is the Document Shepherd for this document? Has the
>      Document Shepherd personally reviewed this version of the
>      document and, in particular, does he or she believe this
>      version is ready for forwarding to the IESG for publication?

Loa Andersson is the Document Shepherd.
He has reviewed the document and believes it is ready to be
forwarded to the IESG for publication.

> (1.b) Has the document had adequate review both from key WG members
>      and from key non-WG members? Does the Document Shepherd have
>      any concerns about the depth or breadth of the reviews that
>      have been performed?

The review has been substantial.
Considerable input to early revisions was received from MPLS WG
participants and from a detailed review by members of ITU-T Study
Group 15.

The WG last call was liaised to the ITU-T, and we have received an
acknowledgement that they also see the document ready for publication.

There was a joint WG last call between the MPLS, PWE3 and CCAMP working
groups. A notificatiion of the WG last call was also sent to the mpls-tp
mailing list. A liaison requesting that ITU-T comments were sent to ITU-T.
The response to that liaison was an ackwoledgement to go ahead.

> (1.c) Does the Document Shepherd have concerns that the document
>      needs more review from a particular or broader perspective,
>      e.g., security, operational complexity, someone familiar with
>      AAA, internationalization or XML?

No. The document includes details of network management features, but
was authored and reviewed by people active in the Operations Area.

> (1.d) Does the Document Shepherd have any specific concerns or
>      issues with this document that the Responsible Area Director
>      and/or the IESG should be aware of? For example, perhaps he
>      or she is uncomfortable with certain parts of the document, or
>      has concerns whether there really is a need for it. In any
>      event, if the WG has discussed those issues and has indicated
>      that it still wishes to advance the document, detail those
>      concerns here. Has an IPR disclosure related to this document
>      been filed? If so, please include a reference to the
>      disclosure and summarize the WG discussion and conclusion on
>      this issue.

No such concerns.

> (1.e) How solid is the WG consensus behind this document? Does it
>      represent the strong concurrence of a few individuals, with
>      others being silent, or does the WG as a whole understand and
>      agree with it?

Development of the document was started within the MPLS-TP design
team (around 20 people) that strongly supports the work. Later the document
has been under the revision control of the MPLS working group. There has
also been some discussion on the MPLS-TP (open) mailing list, and there
were no objections raised.

> (1.f) Has anyone threatened an appeal or otherwise indicated extreme
>      discontent? If so, please summarise the areas of conflict in
>      separate email messages to the Responsible Area Director. (It
>      should be in a separate email because this questionnaire is
>      entered into the ID Tracker.)

No threats or extreme discontent.

> (1.g) Has the Document Shepherd personally verified that the
>      document satisfies all ID nits? (See the Internet-Drafts Checklist
>      and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
>      not enough; this check needs to be thorough. Has the document
>      met all formal review criteria it needs to, such as the MIB
>      Doctor, media type and URI type reviews?

All checks are clean, since the document references other IDs that
are actively being worked on, there tends to be newer versions of
some of the referenced documents.


> (1.h) Has the document split its references into normative and
>      informative? Are there normative references to documents that
>      are not ready for advancement or are otherwise in an unclear
>      state? If such normative references exist, what is the
>      strategy for their completion? Are there normative references
>      that are downward references, as described in [RFC3967]? If
>      so, list these downward references to support the Area
>      Director in the Last Call procedure for them [RFC3967].

References are correctly split.

There are one normative references to an I-D progressed by the mpls
working group (The MPLS-TP Framework), this I-D are ready for WG last
call shortly.

> (1.i) Has the Document Shepherd verified that the document IANA
>      consideration section exists and is consistent with the body
>      of the document? If the document specifies protocol
>      extensions, are reservations requested in appropriate IANA
>      registries? Are the IANA registries clearly identified? If
>      the document creates a new registry, does it define the
>      proposed initial contents of the registry and an allocation
>      procedure for future registrations? Does it suggest a
>      reasonable name for the new registry? See [RFC5226]. If the
>      document describes an Expert Review process has Shepherd
>      conferred with the Responsible Area Director so that the IESG
>      can appoint the needed Expert during the IESG Evaluation?

There are no IANA actions associated with this document.

A null IANA section is present.


> (1.j) Has the Document Shepherd verified that sections of the
>      document that are written in a formal language, such as XML
>      code, BNF rules, MIB definitions, etc., validate correctly in
>      an automated checker?

No such formal language.

> (1.k) The IESG approval announcement includes a Document
>      Announcement Write-Up. Please provide such a Document
>      Announcement Write-Up? Recent examples can be found in the
>      "Action" announcements for approved documents. The approval
>      announcement contains the following sections:

Technical Summary

  The document provides the network management framework for the
  Transport Profile of Multi-Protocol Label Switching (MPLS-TP). It
  relies on the management terminology from the ITU-T and describes
  a NM architecture for the Transport Profile of MPLS.

  Such management could be based on multi-tiered distributed management
  systems.  Thes document provides network and element management
  architectures that could be applied.


Working Group Summary

  The document is part of the MPLS-TP project, the cooperation
  between IETF and ITU-T to specify an MPLS transport profile.
  There are no outstanding issues. It is put on the standards
  track to resolve issues around how the ITU-T references IETF
  documents.

Document Quality

  The document is a framework document and will mainly be used
  as input to the network management solutions specifications
  that will be published shortly.