Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks
draft-ietf-mpls-oam-requirements-07

[Ballot discuss]
As the OPS AD responsible for Network Management" I want to see the
final revisions of these documents. My understanding is there are
already newre versions going around.

The below are SERIOUS shortcomings. Not sure if they are really
blocking, but for now I list them as DISCUSS, so I have a good
chance that the authors will take a serious look at it.

--- draft-ietf-mpls-oam-requirements-06.txt

- Sect 2 Terminology:
  I see (page 3)
    Head-end Label Switch Router (LSR): The beginning of a label
          switched path.
  and I see (also page 3):
    Head-end Label Switching Router (LSR): The beginning of a label
          switched path. A head-end LSR is also referred to as
          an Ingress Label Switching Router.
  Not sure I see/understand the difference (if there is any).
  To me, it looks more as inconsitencies within the single document.

  I see (page 3):
    Collecting traffic: Passive measurement of network traffic.
  It appears twice (page 3 and page 4), but that does not make
  it less weird to me. What is it?

  I see (page 3):
    Probe-based-detection: Active measurement using a tool such as
          LSP ping.
  but I see it again on page 4. Why ??

- I find the usage of MAY (capitalized) quite confusing and distracting.
  I know that Mark has suggested to not botehr at this stage. But
  I do find it troubling. Specifically since sect.2 seems to attach the
  RFC2119 meaning to this capitilized MAY.
  It is so much more disturbing becuase many of the SHOULD and MUST
  cases do indeed make sense.

- 4.9 Standard Management Interfaces
  It is unclear if the "required common information modeling of
  management and control of OAM functionality"  is met by the listed
  MIB module (note "MIB modules" as ipposed to "MIBs"), or if the
  idea is that more work needs to be done. I also wonder if ITU agrees
  that MIB modules is the answer to this requirement.

- I'll note that the titles in the Normative References sections are
  incorrect (i.e. not in sync with the real titles of the RFCs). And
  those are the documents for which some authors of THIS document are
  listed as co-AUTHORSE of those referenced documents.

--- draft-ietf-mpls-oam-frmwk-03.txt

The MPLS OAM framework document confuses me.
Framework documents often do so. Probably because my understanding
of a framework document is that it gives a picture of how all
existing things fit together in a framework, and (even more important)
how coming things can/should fit into the framework.

This document to me seems more of an "overview" or "discussion" of
various FCAPS aspects w.r.t. MPLS.  I think the comments from one of
the MIB doctors basically expresses the same concern.

So I would prefer to see the title changed to reflect that.
Since a new revision is expected anyway, I am taking a DISCUSS,
but I won't keep blocking if the WG decides they want to stick to
the existing title.

[Ballot comment]
---------- MIB Doctor comments
Since new revisions are expected on both documents, let me just copy
some MIB doctor review comments, so that the authors can take this
into consideration for the new revisions.

--- from Mike Heard:

NITs in draft-ietf-mpls-oam-requirements-06.txt: abstract uses the imperative
"MAY" in a context where the ordinary verb "may" is required (the same error
occurs at other places in the document;  I don't think imperatives belong
here at all).  Some acronyms in the abstract also may need to be expanded
there (judgment call).  Also replace "this draft" by "this document".  In
Section 2 please exand "LSP" and "TE" and all other acronyms on or prior to
first use (reverse order of subsections if necessary).  Eliminate one of the
duplicate definitions of "Head-end Label Switch Router".  More substantive:
it is news to me that ICMP is part of the MPLS control plane (sec. 4.1) ...
I thought it was part of the data plane, as far as MPLS was concerned.  I
stop here on minor things that should have been corrected before the doc
went to the IESG (grumble).  Having said all that, I would be OK to have it
published once it got cleaned up (assuming that the responsible AD can vouch
that the MPLS network operator community is happy with its content.

Regarding draft-ietf-mpls-oam-frmwk-03.txt -- the title led me to expect some
real content regarding how OAM would be carried out on MPLS networks.  I didn't
see any.  I am not sure what purpose this document serves.  I do not understand
why it needs to be published.

---- from Dan Romascanu:
draft-ietf-mpls-oam-requirements-06.txt

4.9 Standard Management Interfaces

  The wide-spread deployment of MPLS requires common information
  modeling of management and control of OAM functionality. This is
  reflected in the the integration of standard MPLS-related MIBs
  (e.g. [RFC3813][RFC3812][RFC3814]) for fault, statistics and
  configuration management. These standard interfaces provide
  operators with common programmatic interface access to
  operations and management functions and their status.


... Beyond the word repetition in the 3rd line ...

What is (are) the requirement(s)? This is in a requirements section. A
common information model? Which one, needs it be defined in the IETF,
some other place? SNMP support? Define another MIB module for MPLS OAM?
The listed MIB documents have no direct relation with MPLS OAM.

I believe that this section needs clarification and re-wording


---- from Bert Wijnen:
I actually reviewed a pre-copy of revision 4 for the frmwrk doc:

- I do not see why there is thus MUST/SHOULD/etc in the Terminology
  section. Only MUST is used once in the Security Considerations,
  and even there, a lower case must makes much more sense
- typos:
  section 1:
    the required the applicability of data plane OAM functions. Included
  s/the// at least once?
  figure 1:
  s/dignose/diagnose/
  top of page 7:
    able to automatically remove the defective resources from and the
  s/and// ??
- Mmmm I wonder:
  sect 2:
    FCAPS        Fault management, Configuration management,
                Administration management, Provisioning
                management, and Security management
  I thought that the P stands for Performance and not Provisioning.
  Anyway, if "Provisioning" is intended, then you may want to be
  consistent throughout your dopcument.
  sect 7, end of 2nd para:
    and authorization for OAM technologies is something that MUST be
    considered when designing network mechanism which satisfy the
    requirements presented in this document.
  I though "this document" is a "Framework" and not a "Requirements"
  document??

[Ballot discuss]
As the OPS AD responsible for Network Management" I want to see the
final revisions of these documents. My understanding is there are
already newre versions going around.

The below are SERIOUS shortcomings. Not sure if they are really
blocking, but for now I list them as DISCUSS, so I have a good
chance that the authors will take a serious look at it.

--- draft-ietf-mpls-oam-requirements-06.txt

- Sect 2 Terminology:
  I see (page 3)
    Head-end Label Switch Router (LSR): The beginning of a label
          switched path.
  and I see (also page 3):
    Head-end Label Switching Router (LSR): The beginning of a label
          switched path. A head-end LSR is also referred to as
          an Ingress Label Switching Router.
  Not sure I see/understand the difference (if there is any).
  To me, it looks more as inconsitencies within the single document.

  I see (page 3):
    Collecting traffic: Passive measurement of network traffic.
  It appears twice (page 3 and page 4), but that does not make
  it less weird to me. What is it?

  I see (page 3):
    Probe-based-detection: Active measurement using a tool such as
          LSP ping.
  but I see it again on page 4. Why ??

- I find the usage of MAY (capitalized) quite confusing and distracting.
  I know that Mark has suggested to not botehr at this stage. But
  I do find it troubling. Specifically since sect.2 seems to attach the
  RFC2119 meaning to this capitilized MAY.
  It is so much more disturbing becuase many of the SHOULD and MUST
  cases do indeed make sense.

- 4.9 Standard Management Interfaces
  It is unclear if the "required common information modeling of
  management and control of OAM functionality"  is met by the listed
  MIB module (note "MIB modules" as ipposed to "MIBs"), or if the
  idea is that more work needs to be done. I also wonder if ITU agrees
  that MIB modules is the answer to this requirement.

- I'll note that the titles in the Normative References sections are
  incorrect (i.e. not in sync with the real titles of the RFCs). And
  those are the documents for which some authors of THIS document are
  listed as co-AUTHORSE of those referenced documents.

--- draft-ietf-mpls-oam-frmwk-03.txt

The MPLS OAM framework document confuses me.
Framework documents often do so. Probably because my understanding
of a framework document is that it gives a picture of how all
existing things fit together in a framework, and (even more important)
how coming things can/should fit into the framework.

This document to me seems more of an "overview" or "discussion" of
various FCAPS aspects w.r.t. MPLS.  I think the comments from one of
the MIB doctors basically expresses the same concern.

So I would prefer to see the title changed to reflect that.
Since a new revision is expected anyway, I am taking a DISCUSS,
but I won't keep blocking if the WG decides they want to stick to
the existing title.

[Ballot comment]
---------- MIB Doctor comments
Since new revisions are expected on both documents, let me just copy
some MIB doctor review comments, so that the authors can take this
into consideration for the new revisions.

--- from Mike Heard:

NITs in draft-ietf-mpls-oam-requirements-06.txt: abstract uses the imperative
"MAY" in a context where the ordinary verb "may" is required (the same error
occurs at other places in the document;  I don't think imperatives belong
here at all).  Some acronyms in the abstract also may need to be expanded
there (judgment call).  Also replace "this draft" by "this document".  In
Section 2 please exand "LSP" and "TE" and all other acronyms on or prior to
first use (reverse order of subsections if necessary).  Eliminate one of the
duplicate definitions of "Head-end Label Switch Router".  More substantive:
it is news to me that ICMP is part of the MPLS control plane (sec. 4.1) ...
I thought it was part of the data plane, as far as MPLS was concerned.  I
stop here on minor things that should have been corrected before the doc
went to the IESG (grumble).  Having said all that, I would be OK to have it
published once it got cleaned up (assuming that the responsible AD can vouch
that the MPLS network operator community is happy with its content.

Regarding draft-ietf-mpls-oam-frmwk-03.txt -- the title led me to expect some
real content regarding how OAM would be carried out on MPLS networks.  I didn't
see any.  I am not sure what purpose this document serves.  I do not understand
why it needs to be published.

---- from Dan Romascanu:

4.9 Standard Management Interfaces

  The wide-spread deployment of MPLS requires common information
  modeling of management and control of OAM functionality. This is
  reflected in the the integration of standard MPLS-related MIBs
  (e.g. [RFC3813][RFC3812][RFC3814]) for fault, statistics and
  configuration management. These standard interfaces provide
  operators with common programmatic interface access to
  operations and management functions and their status.


... Beyond the word repetition in the 3rd line ...

What is (are) the requirement(s)? This is in a requirements section. A
common information model? Which one, needs it be defined in the IETF,
some other place? SNMP support? Define another MIB module for MPLS OAM?
The listed MIB documents have no direct relation with MPLS OAM.

I believe that this section needs clarification and re-wording


---- from Bert Wijnen:
I actually reviewed a pre-copy of revision 4 for the frmwrk doc:

- I do not see why there is thus MUST/SHOULD/etc in the Terminology
  section. Only MUST is used once in the Security Considerations,
  and even there, a lower case must makes much more sense
- typos:
  section 1:
    the required the applicability of data plane OAM functions. Included
  s/the// at least once?
  figure 1:
  s/dignose/diagnose/
  top of page 7:
    able to automatically remove the defective resources from and the
  s/and// ??
- Mmmm I wonder:
  sect 2:
    FCAPS        Fault management, Configuration management,
                Administration management, Provisioning
                management, and Security management
  I thought that the P stands for Performance and not Provisioning.
  Anyway, if "Provisioning" is intended, then you may want to be
  consistent throughout your dopcument.
  sect 7, end of 2nd para:
    and authorization for OAM technologies is something that MUST be
    considered when designing network mechanism which satisfy the
    requirements presented in this document.
  I though "this document" is a "Framework" and not a "Requirements"
  document??

[Ballot comment]
---------- MIB Doctor comments
Since new revisions are expected on both documents, let me just copy
some MIB doctor review comments, so that the authors can take this
into consideration for the new revisions.

--- from Mike Heard:

NITs in draft-ietf-mpls-oam-requirements-06.txt: abstract uses the imperative
"MAY" in a context where the ordinary verb "may" is required (the same error
occurs at other places in the document;  I don't think imperatives belong
here at all).  Some acronyms in the abstract also may need to be expanded
there (judgment call).  Also replace "this draft" by "this document".  In
Section 2 please exand "LSP" and "TE" and all other acronyms on or prior to
first use (reverse order of subsections if necessary).  Eliminate one of the
duplicate definitions of "Head-end Label Switch Router".  More substantive:
it is news to me that ICMP is part of the MPLS control plane (sec. 4.1) ...
I thought it was part of the data plane, as far as MPLS was concerned.  I
stop here on minor things that should have been corrected before the doc
went to the IESG (grumble).  Having said all that, I would be OK to have it
published once it got cleaned up (assuming that the responsible AD can vouch
that the MPLS network operator community is happy with its content.

Regarding draft-ietf-mpls-oam-frmwk-03.txt -- the title led me to expect some
real content regarding how OAM would be carried out on MPLS networks.  I didn't
see any.  I am not sure what purpose this document serves.  I do not understand
why it needs to be published.

---- from Dan Romascanu:

4.9 Standard Management Interfaces

  The wide-spread deployment of MPLS requires common information
  modeling of management and control of OAM functionality. This is
  reflected in the the integration of standard MPLS-related MIBs
  (e.g. [RFC3813][RFC3812][RFC3814]) for fault, statistics and
  configuration management. These standard interfaces provide
  operators with common programmatic interface access to
  operations and management functions and their status.


... Beyond the word repetition in the 3rd line ...

What is (are) the requirement(s)? This is in a requirements section. A
common information model? Which one, needs it be defined in the IETF,
some other place? SNMP support? Define another MIB module for MPLS OAM?
The listed MIB documents have no direct relation with MPLS OAM.

I believe that this section needs clarification and re-wording

[Ballot discuss]
Overall, draft-ietf-mpls-oam-frmwk is in much better shape than draft-ietf-mpls-oam-requirements. I have two small nits on the former, and many comments/discusses on the latter.

On draft-ietf-mpls-oam-frmwk-03.txt:

>
>
>        applications that use the LSPs. For instance, TCP is capable of
>        re-ordering packets belonging to a specific flow.
>
Comment: Yes, but not without causing TCP some heartache in the process, perhaps this should be lightly referred to.

>    forwarding path is ot a return path requirement) to mitigate
>
Comment: Nit: ~ot

draft-ietf-mpls-oam-requirements-08.txt:

Note that this review was based on draft-ietf-mpls-oam-requirements-08 (rather than -06), sent to me directly by the author after it was sent to internet-drafts.

Abstract is too long, misformatted, repetitive, and lacks clarity overall. You could probably just delete the first paragraph (which looks like two due to mis-spacing), as a start to fixing this.

Starting with the second paragraph:

> This document describes requirements for user and data plane
> operations and management for MPLS. These requirements have been
> gathered from network operators who have extensive experience
> deploying MPLS networks, similarly some of these requirements have
> appeared in other documents.

Above sentence is a run-on, and really begs the question as to which "other documents" you are referring to.

> This draft specifies Operations and Management requirements for
> Multi-Protocol Label Switching,

The above sentence is completely redundant with the first sentence in this paragraph.

> as well as for applications of Multi-Protocol Label Switching such as
> pseudowire voice and virtual private network services.

You don't have to keep spelling out MPLS, you didn't earlier so I don't know why you are now. The above sentence essentially repeats what is in the first paragraph anyway, but for PWs and voice instead of ATM and FR.

> Those interested in specific issues relating to instrumenting MPLS
> for Operations and Management purposes are directed to the
> Multi-Protocol Label Switching Architecture specification.

The last sentence is better in the introduction section, with the proper reference included.

OK, please rewrite this abstract, I think you could do it in 2-3 sentences, maximum.

> provider organizations today. These requirements can then be use

s/today/at the time this document was written.

Formatting in section 2 is inconsistent and horribly difficult to parse.

> Probe-based-detection: Active measurement using a tool such as Label
> Switched Path Ping.

Reference to lsp-ping?

> Head-end Label Switching Router (LSR): The beginning of a label
> switched path. A head-end LSR is also referred to as an Ingress Label
> Switching Router.

I see "Head-end" LSR used once in this document, an ingress LSR used many times. Can you just delete the use of this term entirely, and move to Ingress LSR throughout?

s/Ingress Label Switching Router/Ingress LSR (you've already defined LSR).

If you have a definition for "Ingress LSR" should you not have one for "Egress LSR"?

> Probe-based-detection

> Collecting traffic:

These terms exist twice in section 2.

Capitalization for all latency/delay terms is inconsistent with the rest of the section (in fact, there are no capital letters at all, except one acronym LSR).

> reesulting

Spelling error, please run doc through a spellchecker (I see several other cases now).

Section 2.2

If you define CE, shouldn't you also define PE?

Section 3 seems to be articulated in the Introduction already. You could delete it to save bits.

Section 4: "harmonized"? Would that be a major or minor chord? Seriously, does that mean they are the same? Similar?

Section 4.1, It seems to me that the first two SHOULDs should be MUSTs. In fact, throughout the doc there are SHOULDs that I think could be MUSTs. This kind of change would require a spin through the WG again though, so I won't push on it given we are expediting.

Also in Section 4.1, the first (long) paragraph seems to cover two important requirements. One, not requiring hop-by-hop intervention, the other reporting a defect before the customer notices. I think you can separate this into two paragraphs to aid readability and highlight the separate requirements.

> broken LSPs is required. Failure to specifying defect detection

s/specifying/specify

> Providers and their customers MAY need to verify high-level

Some MAYs in this doc probably do not need capitalizing, for example the one above.

[Ballot discuss]
Note that this review was based on draft-ietf-mpls-oam-requirements-08, sent to me directly by the author after it was sent to internet-drafts.

Some of these are comments, but taken as a whole I am marking it as discuss.

draft-ietf-mpls-oam-requirements-08:

Abstract is too long, misformatted, repetitive, and lacks clarity overall. You could probably just delete the first paragraph (which looks like two due to mis-spacing), as a start to fixing this.

Starting with the second paragraph:

> This document describes requirements for user and data plane
> operations and management for MPLS. These requirements have been
> gathered from network operators who have extensive experience
> deploying MPLS networks, similarly some of these requirements have
> appeared in other documents.

Above sentence is a run-on, and really begs the question as to which "other documents" you are referring to.

> This draft specifies Operations and Management requirements for
> Multi-Protocol Label Switching,

The above sentence is completely redundant with the first sentence in this paragraph.

> as well as for applications of Multi-Protocol Label Switching such as
> pseudowire voice and virtual private network services.

You don't have to keep spelling out MPLS, you didn't earlier so I don't know why you are now. The above sentence essentially repeats what is in the first paragraph anyway, but for PWs and voice instead of ATM and FR.

> Those interested in specific issues relating to instrumenting MPLS
> for Operations and Management purposes are directed to the
> Multi-Protocol Label Switching Architecture specification.

The last sentence is better in the introduction section, with the proper reference included.

OK, please rewrite this abstract, I think you could do it in 2-3 sentences, maximum.

> provider organizations today. These requirements can then be use

s/today/at the time this document was written.

Formatting in section 2 is inconsistent and horribly difficult to parse.

> Probe-based-detection: Active measurement using a tool such as Label
> Switched Path Ping.

Reference to lsp-ping?

> Head-end Label Switching Router (LSR): The beginning of a label
> switched path. A head-end LSR is also referred to as an Ingress Label
> Switching Router.

I see "Head-end" LSR used once in this document, an ingress LSR used many times. Can you just delete the use of this term entirely, and move to Ingress LSR throughout?

s/Ingress Label Switching Router/Ingress LSR (you've already defined LSR).

If you have a definition for "Ingress LSR" should you not have one for "Egress LSR"?

> Probe-based-detection

> Collecting traffic:

These terms exist twice in section 2.

Capitalization for all latency/delay terms is inconsistent with the rest of the section (in fact, there are no capital letters at all, except one acronym LSR).

> reesulting

Spelling error, please run doc through a spellchecker (I see several other cases now).

Section 2.2

If you define CE, shouldn't you also define PE?

Section 3 seems to be articulated in the Introduction already. You could delete it to save bits.

Section 4: "harmonized"? Would that be a major or minor chord? Seriously, does that mean they are the same? Similar?

Section 4.1, It seems to me that the first two SHOULDs should be MUSTs. In fact, throughout the doc there are SHOULDs that I think could be MUSTs. This kind of change would require a spin through the WG again though, so I won't push on it given we are expediting.

Also in Section 4.1, the first (long) paragraph seems to cover two important requirements. One, not requiring hop-by-hop intervention, the other reporting a defect before the customer notices. I think you can separate this into two paragraphs to aid readability and highlight the separate requirements.

> broken LSPs is required. Failure to specifying defect detection

s/specifying/specify

> Providers and their customers MAY need to verify high-level

Some MAYs in this doc probably do not need capitalizing, for example the one above.

[Ballot discuss]
Note that this review was based on draft-ietf-mpls-oam-requirements-08, sent to me directly by the author after it was sent to internet-drafts.

Abstract is too long, misformatted, repetitive, and lacks clarity overall. You could probably just delete the first paragraph (which looks like two due to mis-spacing), as a start to fixing this.

Starting with the second paragraph:

> This document describes requirements for user and data plane
> operations and management for MPLS. These requirements have been
> gathered from network operators who have extensive experience
> deploying MPLS networks, similarly some of these requirements have
> appeared in other documents.

Above sentence is a run-on, and really begs the question as to which "other documents" you are referring to.

> This draft specifies Operations and Management requirements for
> Multi-Protocol Label Switching,

The above sentence is completely redundant with the first sentence in this paragraph.

> as well as for applications of Multi-Protocol Label Switching such as
> pseudowire voice and virtual private network services.

You don't have to keep spelling out MPLS, you didn't earlier so I don't know why you are now. The above sentence essentially repeats what is in the first paragraph anyway, but for PWs and voice instead of ATM and FR.

> Those interested in specific issues relating to instrumenting MPLS
> for Operations and Management purposes are directed to the
> Multi-Protocol Label Switching Architecture specification.

The last sentence is better in the introduction section, with the proper reference included.

OK, please rewrite this abstract, I think you could do it in 2-3 sentences, maximum.

> provider organizations today. These requirements can then be use

s/today/at the time this document was written.

Formatting in section 2 is inconsistent and horribly difficult to parse.

> Probe-based-detection: Active measurement using a tool such as Label
> Switched Path Ping.

Reference to lsp-ping?

> Head-end Label Switching Router (LSR): The beginning of a label
> switched path. A head-end LSR is also referred to as an Ingress Label
> Switching Router.

I see "Head-end" LSR used once in this document, an ingress LSR used many times. Can you just delete the use of this term entirely, and move to Ingress LSR throughout?

s/Ingress Label Switching Router/Ingress LSR (you've already defined LSR).

If you have a definition for "Ingress LSR" should you not have one for "Egress LSR"?

> Probe-based-detection

> Collecting traffic:

These terms exist twice in section 2.

Capitalization for all latency/delay terms is inconsistent with the rest of the section (in fact, there are no capital letters at all, except one acronym LSR).

> reesulting

Spelling error, please run doc through a spellchecker (I see several other cases now).

Section 2.2

If you define CE, shouldn't you also define PE?

Section 3 seems to be articulated in the Introduction already. You could delete it to save bits.

Section 4: "harmonized"? Would that be a major or minor chord? Seriously, does that mean they are the same? Similar?

Section 4.1, It seems to me that the first two SHOULDs should be MUSTs. In fact, throughout the doc there are SHOULDs that I think could be MUSTs. This kind of change would require a spin through the WG again though, so I won't push on it given we are expediting.

Also in Section 4.1, the first (long) paragraph seems to cover two important requirements. One, not requiring hop-by-hop intervention, the other reporting a defect before the customer notices. I think you can separate this into two paragraphs to aid readability and highlight the separate requirements.

> broken LSPs is required. Failure to specifying defect detection

s/specifying/specify

> Providers and their customers MAY need to verify high-level

Some MAYs in this doc probably do not need capitalizing, for example the one above.

[Ballot discuss]
Section 7 of the management framework implies that it is sufficient to
filter management traffic and that authentication and authorization is
not needed.  I'm skeptical of this claim.  How can we guarantee that
MPLS will not be used along with traditional IP based services?  How
cann we guarantee that it will always be possible to filter things
appropriately?  How well does this work in multi-provider networks?

[Ballot discuss]
draft-ietf-mpls-oam-requirements-06: A normative reference to RFC 2119 needs to be added. I know that some people have issues with such citations in an informational requirements document, but the way words like MUST are being used here and the description of the keywords points to the need for a normative reference.

An RFC Editor note can cover this quite nicely.