Subject: [mpls-tp] working group last call on draft-ietf-mpls-tp-nm-req-01.txt

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 12 May 2009 09:06:20 +0100

Eric, Colleagues,

My LC comments on draft-ietf-mpls-tp-nm-req-01

Section 4:

1)
        In order to have the MCN operate properly, a number of
        management functions for the MCN are required, including:

Is this 'required' or 'REQUIRED', as these functions are key to a MCN
operating at all I guess it should be REQUIRED.

Section 5.1:

2)
s/data-plane/data plane/

3)
          . Supervision of the detection of failure in the sequence of
            a protocol exchange (e.g. automatic protection switching
            protocol);

What does "in the sequence of a protocol exchange" mean? Are you just saying
that a NE MUST be able to supervise failure detection where failures are
detected and possibly reacted to using a protocol of some sort?

4)
s/transmission-related/transmission related/

5)
        The MPLS-TP NE MUST support hardware-related supervision for
        interchangeable and non-interchangeable units, cable, and power
        problem. 

Should cable & problem be plural?

6)
s/environment-related/environment related/

Section 5.2:

7)
Why suddenly start using SHALL instead of MUST?

Section 5.3.2:

8)
s/inter-working/interworking/

9)
        Note: An MPLS-TP NE supporting the inter-working of one or more
        networking technologies (e.g., Ethernet, SDH/SONET, MPLS) with
        MPLS-TP needs to translate an MPLS-TP fault into an existing
        transport technology failure condition for reporting to the
        management system.

The sentence is a bit unclear to me. I think what you're saying is that if
MPLS-TP is used as a server for a different network technology it needs to
be able to translate an MPLS-TP fault into a failure condition that is
meaningful to the client layer so the client layer can report it if it so
desires?

Section 6.2

10)
        Further detailed
        requirements might be provided along with progress in defining
        the MPLS-TP control plane in appropriate specifications.

While true the sentence isn't particularly helpful to a reader to know where
to look for these requirements. As new (or more detailed) requirements
coming along is a natural thing I suggest either point to a specific
document (I guess there isn't one at this time) or remove the sentence.

Section 6.3:

11)
        The MPLS-TP NE MUST support the capability of configuring
        required LSPs as follows:

            . configure LSP indentifier and/or other information
               necessary to retrieve LSP status information.

What's a "required LSP"? Do you really mean "LSP parameters" (i.e. Remove
required and insert parameters)?

12)
s/indentifier/identifier/

Section 6.4

13)
What's "required protection"? Do you really mean "path protection
parameters" (i.e. Remove required and insert parameters)?

Section 6.5

14)
s/apply them/apply them to/

        The MPLS-TP NE MUST have the flexibility to configure OAM
        parameters to meet their specific operational requirements, such
        as whether (1) one-time on-demand immediately or (2) one-time
        on-demand pre-scheduled or (3) on-demand periodically based on a
        specified schedule or (4) proactive on-going.

Think this sentence needs some rework as it's a bit hard to follow IMO,
maybe put items in a numbered list and s/whether/whether to run OAM/

Section 7:

15)
s/Bring-into-service/bringing into service/
s/packet-switched/packet switched/
s/circuit-switched/circuit switched/
s/hybrid network/hybrid networks/

16)
        The MPLS-TP NE MUST support collection of loss ratio measurement
        so that they can be used to determine Severely Errored Second
        (SES). 

I won't get into SES again as we've had this discussion before but I would
comment that I forsee a requirement for packet transport networks to
directly report loss measurements rather than reporting them as SES and so
MPLS-TP NE MUST support collection and reporting of "raw" loss measurements.

17)
We also need a definition of entry/exit criteria for available/unavailable
states when using direct/"raw" loss measurements and not translating them
into SES. This document may not be the place to define that (maybe the OAM
Framework?).

Section 7.2.1

18)
Extra requirement:
MUST support the ability for the measurement frequency to be configured?

Section 7.2.2

19)
'required' or 'REQUIRED' in several places?

Ben

---

From: "tom.petch" <[email-masked]>
Date: Mon, 18 May 2009 07:02:16 +0200

----- Original Message -----
From: "Ben Niven-Jenkins" <[email-masked]>
To: <[email-masked]>
Cc: "Loa Andersson" <[email-masked]>
Sent: Tuesday, May 12, 2009 10:06 AM
Subject: [mpls-tp] working group last call ondraft-ietf-mpls-tp-nm-req-01.txt

> operating at all I guess it should be REQUIRED.

For me this is just one example of several where the layout of the document
leaves me uncertain as to what is and what is not a requirement.

I infer that a sentence containing 'MUST' 'REQUIRED' or 'SHOULD' is a
requirement, but when it is 'required' or something else, then, like Ben, I am
left to guess.

I think that this I-D should follow, even improve on,
'draft-ietf-mpls-tp-requirements-06' in giving us a clearly identified list
separating out editorial matter (of which there is quite a lot) from
requirements.  The one improvement would be that instead of having a single
numeric identifier from 1 to some large number, which means that when a
requirement is added or removed, many of others change identifiers rendering
list comments hard to correlate, that the identifier is two part, eg
S(ecurity)nn or P(erformance)nn or F(ault)nn so that fewer identifiers change in
an update.

And the formatting - margins, indentation etc -seems out of line with RFC
practice, something I always think it best for a WG to fix rather than leaving
it to
the RFC Editor, who has quite enough to look out for already.  (Using XML does
fix all this for me - and you).

Tom Petch

<snip>

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 18 May 2009 16:14:27 +0100

Hi,

Review comments as a contributor to this work.

Thanks,
Adrian

===

Did the authors look at draft-ietf-opsawg-operations-and-management
while writing this document? I believe they should go back and see
whether that I-D identifies any other areas they should cover.

An informational reference should be added.

===

Document status

I believe it is Loa's intention that all of the MPLS-TP requirements
I-Ds will progress on the Standards Track. Please check with him.

===

Abstract

   This document specifies the requirements necessary to manage the
   elements and networks that support an MPLS Transport Profile
   (MPLS-TP). This document is a product of a joint International
   Telecommunications Union - Telecommunications Standardization
   Sector (ITU-T) and Internet Engineering Task Force (IETF) effort
   to include a MPLS Transport Profile within the IETF MPLS
   architecture. The requirements are driven by the management
   functionality needs defined by ITU-T for packet transport
   networks.

I have several problems with this.
1. "...the requirements necessary..."
   Does that mean that the document is a requirements spec for a
   requirements spec? I don't think so :-)
2. "...elements and networks that support an MPLS Transport Profile..."
   I don't think elements or networks do that. I think the elements
   implement an MPLS transport network.
3. I am a little uncomfortable with the precise wording of the joint-
   effort text.
Could we consider the following alternative?

   This document specifies the requirements for the management of
   equipment in an MPLS Transport Profile (MPLS-TP) network. The
   document states the necessary and desirable behaviour of the network
   equipment and specifies the objectives of protocol extensions that
   will be developed to support MPLS-TP.

   This document is the product of a collaborative effort within the
   IETF to specify a profile of MPLS for use within transport networks.
   Contributions to the effort have come from participants in both the
   IETF and the International Telecommunications Union -
   Telecommunications Standardization Sector (ITU-T), and the completed
   document has been reviewed by the ITU-T as well as having had a
   consensus review within the IETF.

===

Section 1

This section seems to be missing any definition or discussion or
reference to what MPLS-TP is.

===

Section 2
"NETCONF/XML or SNMP/SMI, and another domain via CORBA/IDL"

Should you include references for these protocols?

===

Section 2
   The
   protocols to be supported are at the discretion of the operator.

Although the implementor may have some impact on the decision!

===

Section 3

It is not clear to me what "seamless management connectivity" means.
Sounds like salesman speak to me! (Fortunately, it's only a SHOULD.)

===

Section 3 para 2

s/purpose/purposes/

===

Section 3

   For management purpose, every MPLS-TP NE MUST connect to an OS
   either directly or indirectly via another MPLS-TP NE. When an
   MPLS-TP NE is connected indirectly to an OS, an MCC MUST be
   supported between the MPLS-TP NE and the other MPLS-TP NE.

A couple of issues...

- Does the CLI count as an OS? It doesn't look like it from the
  definition in section 1.1. But surely it is acceptable to have
  an NE with only CLI management?
- Why does the indirect connection have to be via another MPLS-TP
  NE? Given the amount of text in Appendix A, this paragraph is
  very restrictive and a bit odd. In particular, there is an MCC
  between each NE and its OS and that MCC can be logical (by
  definition), but if other MPLS-TP NEs lie on the path of that
  MCC, they do not play any role except to forward packets.

===

Section 4

   The MCN connects MPLS-TP NEs
   with management systems, NEs with NEs, and management systems
   with management systems.

The fact that the MCN connects management systems with other management
systems is probably not relevant to this document and should be removed.

The fact that the MCN connects NEs with other NEs is probably only
coincidental and is not relevant to the function provided by the MCN.

===

Section 4

   Transport DCN architecture and
   requirements are specified in ITU-T G.7712/Y.1703 [7], including
   network layer protocols and their interworking.

I think this needs some clarification.

   The architecture and requirements for transport DCNs are specified
   in ITU-T G.7712/Y.1703 [7], including the requirements for DCN
   network layer protocols and their interworking.

===

Section 4

   As a practical requirement, MCN connections require addressing.
   See the section on addressing in [13] for further information.

This is not technically true in all cases. If the MCN comprises
dedcated p2p links...

===

Section 4 seems to focus on the management requirements for the
management network. This could recurse infinitely since presumably
the MCN could be managed using a separate network that would have
its own management requirements.

Does it really need to be in this document?

===

Section 4

   . Capability to enable/disable access to the DCN.

Access by/from whom/what?

===

Section 5.1

   The MPLS-TP NE MUST support the following transmission
   supervision functions:

Does "transmission supervision" mean "data-plane forwarding path
supervision" Using the term in the first bullet)?

===

Section 5.1

s/looping check functions/loop-checking functions/

===

Section 5.1, the bullet points (following the definition of
"supervision") appear to imply that some functions that are
themselves supervisory functions nedd to be supervised. I
don't think this is your objective.

===

Section 5.2

I think the language is a bit loose.

   Validation is concerned with the integration of Fault Causes
   into Failures. A Fault Cause indicates a limited interruption of
   the required transport function. A Fault Cause is not reported
   to maintenance personnel because it could exist only for a very
   short time. Note that some of these events however are summed up
   in the Performance Monitoring process, and when this sum exceeds
   a certain value, a Threshold Report can be generated.

s/Validation is concerned with/Validation is/
s/Fault Causes/Fault Cause indications/
s/Failures/Failure reports/
s/Fault Cause indicates/Fault Cause indication indicates/
s/could/might/
d/however/
s/process,/process (see Section 7),/
s/certain/configured/
s/can/MAY/ ???

And in the rest of the section you need to decide about "fault cause"
or "Fault Cause" and "failure" or "Failure"

===

Section 5.2 defines some time values as "typical". This is not
helpful language in a requirement document. Do you mean RECOMMENDED
or REQUIRED?

What about the ability to configure these timers:
- per failure cause
- per deduced fault
- per NE
- per network
Are any of these requirements?

===

Section 5.3.1

   Failures might be categorized to indicate the severity or
   urgency of the fault.

What kind of requirement is "might be categorised"? Or is this passive
voice actually refering to an event outside the scope of this document
that could drive other requirements?

   An MPLS-TP NE SHOULD support the flexibility of assignment of
   severity (e.g., Critical, Major, Minor, Warning) by the
   management system.

Assignment to what?
And what is the purpose of such assignment at the NE?
I.e., what is the effect of such an assignment on the NE and its
interactions with the outside world?

   See G.7710 [1] for more description about alarm severity
   assignment.

Is this a normative reference or just further information? Given
the sparsity of the requirements in this section, I worry that it
is normative. That will not do - please put the requirements in
this document.

===

Section 5.3.2

   An MPLS-TP NE MUST provide alarm suppression functionality that
   prevents the generation of superfluous alarms.

"superfluous" is either subjective or pointless!

You must either define this term or state a requirement that the
alarm supression policy must be configurable.

   Examples of alarm suppression mechanisms include simply
   discarding the alarms (or not generating them in the first
   place), or aggregating the alarms together, thereby greatly
   reducing the number of alarm notifications to be emitted.

Alarm notification aggregation is not alarm supression. In this
case no alarm is actually supressed. It may be a valid requirement
or function, but it is in the wrong section.

s/aggregating the alarms together/aggregating the alarms/

   See RFC 4377 [2] for more description.

The text of the note differs significantly from that in 4377. 4377
talks about the "inter-working of one or more networking technologies
*over* MPLS". Further, the translation of failure conditions described
in 4377 is about making server layer faults comprehensible as client
layer faults.

I think this Note is at best ambiguous and at worst false and should
be removed. Further, "needs to translate" is not correct reuqirements
language, and requirements should not be expressed in "notes".

===

Section 5.3.3

   Alarm Reporting Control (ARC) supports an automatic in-service
   provisioning capability. Alarm reporting MAY be turned off on a
   per-managed entity (e.g., LSP) basis to allow sufficient time
   for customer service testing and other maintenance activities in
   an "alarm free" state. Once a managed entity is ready, alarm
   reporting is automatically turned on.

Horse is driving cart here.
It is interesting to know a usage you intend to make of the required
function, but please state the requirements separate from the usage.
The use itself is not a requirement, and the justifiction for a
requirement is secondary.

   An MPLS-TP NE SHOULD support the Alarm Reporting Control
   function for controlling the reporting of alarm conditions.

"SHOULD" or "MAY"? The previous paragraph says "MAY", but applies
it to a specific variation of ARC. Probably the paragraphs need to
be reversed.

   See G.7710 [1] and RFC 3878 [9] for more description of ARC.

Again, is this a normative reference or just further information?

===

Section 5.3.4

Shouldn't this section come before 5.3.3?
How can you define the requirements for control of a function before
you have defined the requirements for the function?

Looks to me that it should also come before 5.3.2 since it is the
alarm reporting that you want to supress.

   Local reporting is concerned with automatic alarming by means of
   audible and visual indicators near the failed equipment.

   An MPLS-TP NE MUST support local reporting of alarms.

   The MPLS-TP NE MUST support reporting of alarms to an OS. These
   reports are either autonomous reports (notifications) or reports
   on request by maintenance personnel. The MPLS-TP NE SHOULD
   report local (environmental) alarms to a network management
   system.

Nice piece of confision here!
"Local reporting of alarms" != "Reporting of local alarms"

Can I suggest that you don't "report an alarm" you "report a condition".
Such a report *is* an alarm.

===

Section 6.1

   The MPLS-TP NE MUST support the configuration requirements
   specified in G.7710 [1] for hardware, software, and date/time.

I am not happy with these requirements by reference.
I do not want you to have to rewrite (or re-type) G.7710, but I do
want this document to be comprehensible to the IETF readership.

In fact, "hardware, software, and date/time" covers just sections
8.1, 8.2, and 8 .13 of G.7710.

Sections 8.1. and 8.2 are so small that they really would be easy to
reproduce here as concrete requirements.

Section 8.13 is very complex. I don't believe that all of the section
belongs in this I-D (and certianly not in this section of this I-D),
but it contains sufficient important details that I believe this
requirement should be properly stated in IETF terminology in this
document.

===

Section 6.2

s/might/will/

===

Section 6.3

The content of this section really suprised me. Perhaps the section
name is wrong.

I think you need to think a bit harder about what is actually
configured on an NE, and what an NE can know about.

===

Section 6.4

Is this function really required for every LSP on every NE?

I believe it would be helpful to state the requirements more
specifically. For example, it is only necessary to designate
LSPs as working or protection LSPs at switching points of
protected LSPs.

===

Section 7.1 is going to cause some debate.

It seems to me that if I send one packet in a one second window, and
that packet is lost, I have a 100% loss ratio and an SES. But if I
send 10,000 packets and drop 1,000 it is only a 10% loss ratio which
might be acceptable. Surely this definition of SES is not helpful.

Some of the terms in this section are not adequately defined. For
example LM, DM, Performance degradation, loss ratio measurement, UAS.

   SES and UAS history (the number of readings to be retained and
   available) is as defined in ITU and ANSI documents associated
   with specific transport technologies (for instance, ITU-T
   G.7710, and ANSI T1.231-2003 [T1.231.01-2003 for DSL,.02 for
   DS1,.03 for DS3 and T1.231.04-2003 for SONET] - see [1] and [14]
   respectively), however these are fairly consistently defined as
   follows:

Very interesting :-)
Now, would you care to state some requirements for MPLS-TP?

===

Section 7.2.1

   The performance measurement mechanisms MUST support the
   flexibility to be configured to operate on-demand or proactively
   (i.e. continuously over a period of time).

"Configured to operate proactively" sounds like "on-demand" to me.

Perhaps there is some other requirement here about being configured
to run for a specific period or enabled and left running until
explicitly disabled.

===

Section 7.2.2

   Note: for associated bidirectional P2P connections, this data
   can only be measured at end-points.

It is unclear to which requirements this statement applies.

===

In Section 8.1 it is not clear when security is required.

In the first paragraph you have

   Secure channels MUST be provided for all network traffic and
   protocols used to support management functions.

This sounds like a deployment requirement rather than an
implementation requirement.

But in the second paragraph you have:

   If management communication security is provided, the MPLS-TP NE
   MUST support the following:

That sounds like MCC security implementation may be optional.

Meanwhile, in paragrahp 1 you have:

   The MCC MUST support application
   protocols that provide confidentiality and data integrity
   protection.

That doesn't sound much like a requirement on the MCC that it
can easily understand or meet. The MCC is a pipe for the application
protocols - how can it actively support or not support application
protocols that provide confidentiality and data integrity proteciton?

===

Section 9

s/MAY/may/

===

Section 12.1

If the I-D is repositioned as Standards Track (see first comment) we
need to look at the status of the normative references to try to avoid
downrefs if possible (although we can call them out in last call).
I see: RFC 4377, RFC 4732, RFC 3871,
Not sure if 4377 could be an informational reference, but pretty sure
that 4732 and 3871 could be.

===

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 18 May 2009 18:15:06 +0100

>    consensus review within the IETF.

Or the following based on the text in draft-ietf-mpls-tp-requirements-08
modified slightly to apply only to network management

   This document specifies the requirements for the management of equipment
   in an MPLS Transport Profile (MPLS-TP) network.  The requirements are for
   the behavior of the protocol mechanisms and procedures that constitute
   building blocks out of which the MPLS transport profile is constructed.
   That is, the requirements indicate what features are to be available in
   the MPLS toolkit for use by MPLS-TP.  The requirements in this document
   do not describe what functions an MPLS-TP implementation supports.  The
   purpose of this document is to identify the toolkit and any new
   protocol work that is required.

   Although this document is not a protocol specification, the key words
   "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are used as
   described in [RFC2119] and are to be interpreted as instructions to
   the protocol designers producing solutions that satisfy the
   requirements set out in this document.

   This document is a product of a joint ITU-T and IETF effort to
   include an MPLS Transport Profile within the IETF MPLS and PWE3
   architectures to support the capabilities and functionalities of a
   packet transport network as defined by ITU-T.

   This work is based on two sources of requirements, MPLS and PWE3
   architectures as defined by IETF and packet transport networks as
   defined by ITU-T.  The requirements for the management of equipment
   in an MPLS-TP network are provided below. The relevant functions of MPLS
   and PWE3 are included in MPLS-TP, except where explicitly excluded.

Ben