Subject: [mpls] FW: Last Call review of draft-ietf-mpls-tp-mib-management-overview-04

From: Eric Gray <[email-masked]>
Date: Tue, 21 Jun 2011 10:48:50 -0400

Forwarding in plain text...

________________________________

From: Daniel King [mailto:[email-masked]]
Sent: Tuesday, June 21, 2011 6:50 AM
To: Eric Gray
Cc: [email-masked]; [email-masked]
Subject: RE: Last Call review of draft-ietf-mpls-tp-mib-management-overview-04

Hi Eric,

Thanks for taking the time to review the draft thoroughly. As usual, a great review. We will issue a new version of the draft at the end of the LC period to address your, and any other, comments. We will then follow-up up with you to make sure your points have been addressed.

Br, Dan.

From: Eric Gray [mailto:[email-masked]]
Sent: 20 June 2011 19:12
To: [email-masked]
Cc: [email-masked]
Subject: Last Call review of draft-ietf-mpls-tp-mib-management-overview-04

This is my comments on this version for WG Last Call.

This is generally a very useful piece of work.  Most of my comments are related

to front matter (prior to section 4 where most of the "meat" of the draft starts), or

in other text which has probably not received recent review.

This review is for the draft located at:

http://tools.ietf.org/html/draft-ietf-mpls-tp-mib-management-overview-04

Comments/Questions

================

Abstract: Why use "would be required" to describe additional MIB modules?

Are they required, or does the requirement hinge on some other dependency?

Introduction:

Second paragraph: s/responsibility of the modules/responsibility for the modules/

Third paragraph: Why do you explicitly refer to the GMPLS control plane, when it

is clearly the case that a transport path may be PW-based and PW signaling is

based on LDP?  And, once the signaling context is expanded to include any form

of MPLS signaling, why limit the context of this paragraph to MPLS-TP?  Any LSP

or PW can be statically provisioned.

Fourth paragraph: instead of "architecture for MPLS-TP" we should say "architecture

for MPLS, as extended for MPLS-TP" - because there is not (AFAIK) intended to be

any restriction in the applicability of this management architecture to just MPLS-TP.

Also in the fourth paragraph, please break the first sentence into two parts.  And, we

again say "would be required", implying in this specific context "if anyone, anywhere,

ever even thinks they might use SNMP for the management interface."  Does it seem

likely that this will not be the case?

Section 1.1:

First paragraph:  There is a problem with the two phrases "the MPLS-TP networks"

and "its client networks" (this can happen when using too many such phrases in a

sentence).  As I understand the sentence (based on how it is now written), it means

to say:

"MPLS-TP network management is inseparable from client network management so

that the same management approach can be used regardless of the client."

Once I think I have teased out the meaning of this sentence, I find that it is wrong.

Instead of being "inseparable", it should be "separable" or "independent" (since the

intent appears to be to allow MPLS-TP network to be managed independent of the

way that client networks are managed).

Also in the first paragraph, "management functions ... includes" should be either

"management functions ... include", or "management function ... includes" (given

the opening of the next paragraph, I suspect the latter choice is more appropriate).

Second paragraph: the first sentence in this paragraph needs work.  Is the purpose

of the management function to provide control, monitoring and procedures (where

control and monitoring applies to protocol mechanisms, and procedures applies to

building blocks for ...) or is it to provide control and monitoring of both protocol

mechanisms and procedures?  Also, assuming that a "profile" is supposed to be a

subset, why do we need "building blocks" for a transport profile of MPLS?

Again, this is the problem with viewing MPLS-TP as separate from MPLS.  We've

defined extensions to MPLS, such that we can define a transport profile.  Building

blocks in this case are these extensions and apply to MPLS generally, even though

added to MPLS to allow definition of a transport profile.

Section 2: PW terminology references are conspicuously missing from this section.

Minimally, the PWE3 architecture (RFC 3985) should be included here.

Section 4.2.3: This section provides a doubtful description of a Label Edge Router.

Unfortunately, I am not aware of any RFC or other draft that defines this concept.

It is certainly not explicitly defined in any of the RFCs listed in section 2 (where

a list of RFCs is provided for terminology sources) - though it is used in at least

one of them.

I suggest that you provide a definition "for the purposes of this document" in the

Terminology section.  From a management perspective, your description is very

convenient.  In general, however, an LER typically provides either ingress to, or

egress from, an LSP.  Since LSPs may be hierarchical, it is not even clear that

an LER will necessarily be mapping a network layer header (directly) to an FTN

(the mapping may be implied by any of a set of labels that each map to a subset

of the intended FEC).

>From a management perspective, the simple description you use is sufficient, if

not necessarily complete.  It should be clear, however, that you are not defining

the term LER to generally mean what you have in this section, since that would

likely provoke some person - at some later time - to ask "well, what do we call a

device that is an egress to LSPs?"

Section 4.2.5: This section provides a doubtful (if intuitive) description of an Label

Switched Path.  Part of the problem is that "MPLS domain" is a bit nebulous.  An

LSP begins where a set of one or more labels is prepended to a previously existing

network layer or MPLS label header (thus forming, or adding to, a label stack).  The

LSP continues through an arbitrary number of 0 or more LSRs where a top-of-stack

label is swapped for the appropriate corresponding downstream label.  Finally, the

LSP ends at the LSP egress (which will either be where the last label in the set is

removed, or at the next LSR after this last label is removed - if PHP is used and the

LSR removing the label is the penultimate hop).  At any LSR along the LSP, the

local view of an LSP comprises eitehr an FTN or an ILM (which - for management

purposes is represented by in-segment and out-segment mappings).

The issue with the description you provide is that 1) it is more than just the path

taken (many LSPs may follow the same path) and 2) any LSP may be carried in

another LSP, which itself may not traverse the entire MPLS domain.

Label Switched Path is defined in very explicit and precise detail in RFC 3031.

Section 4.2.6:

In the first paragraph, why is there a line break between "layered" and "modular"?

Section 4.2.8:

First paragraph - This sentence/paragraph needs work. Possibly it should start

"The purpose of MPLS resiliency is ..."  Also, "no interruption" seems hardly to

be likely - perhaps "minimal interruption"?

Section 4.2.10:

There are problems with the dependency chart in this section.  First, it is not too

obvious how to resolve dependencies where lines intersect.  After some trouble, I

realized that your use of arrows going into the intersection seems to mean that a

dependency is one way.  So - for example - that means -

    MPLS-TE-STD-MIB ---> MPLS-TC-STD-MIB

    MPLS-FTN-STD-MIB ---> MPLS-TC-STD-MIB

    MPLS-LDP-GENERIC-STD-MIB ---> MPLS-TC-STD-MIB

    MPLS-LDP-STD-MIB ---> MPLS-TC-STD-MIB

    etc. -

but not the other way around (nor is there - for example - a direct dependency

between MPLS-FTN-STD-MIB and MPLS-LDP-GENERIC-STD-MIB).

This notation is broken when it comes to the relationship between the following:

    MPLS-TE-STD-MIB and ...

    GMPLS-LSR-STD-MIB and ...

    GMPLS-TE-STD-MIB  and ...

    PW-MPLS-STD-MIB and ...

These look like they may all be dependent on both MPLS-LSR-STD-MIB and

MPLS-FTN-STD-MIB - probably because of a missing arrow on the left side

(pointing right) of an intersection where these all come together (although you

might argue that the absence of an arrow pointing left on the dashed-line going

left from this intersection means that the dependency doesn't go that way).

I wonder if this chart might not be simplified somewhat by taking out indirect

(or implicit) dependencies.  For example (if I am reading this right),

    MPLS-LDP-GENERIC-STD-MIB ---> MPLS-LDP-STD-MIB,

    MPLS-FTN-STD-MIB ---> MPLS-TE-STD-MIB

        and

    MPLS-LDP-STD-MIB ---> MPLS-LSR-STD-MIB,

    MPLS-TE-STD-MIB  ---> MPLS-LSR-STD-MIB

        and

    MPLS-LSR-STD-MIB ---> MPLS-TC-STD-MIB,

means you could remove the dependencies:

    MPLS-FTN-STD-MIB ---> MPLS-LDP-STD-MIB (eliminating the above issue)

    MPLS-LDP-STD-MIB ---> MPLS-TC-STD-MIB

    MPLS-LDP-GENERIC-STD-MIB --> MPLS-TC-STD-MIB

    MPLS-FTN-STD-MIB ---> MPLS-TC-STD-MIB

    MPLS-TE-STD-MIB ---> MPLS-TC-STD-MIB

These dependencies are implied by the dependencies above.

Section 5:

First paragraph, "sub sections" should probably be hyphenated.  Also, there's

something not-quite right about the sentence.  Reading the section, it's the

sub-sections of this section that focus on gaps in the current set of MPLS MIB

modules. Also, if "its" subsitutes for MPLS MIB modules, "its use" should be

"their use."  Lastly, restating an earlier comment, MPLS-TP is not an extension

of MPLS, it's a profile of MPLS as extended.  I suggest re-wording the sentence

as follows:

"The below sub-sections of this section focus on possible gaps in existing MPLS

MIB modules in order to determine extensions or additional MIB modules that are

required to support MPLS-TP in MPLS networks."

Second paragraph, why is there a line-break between "of" and "equipment"?

Third paragraph, why is there a line-break between "for" and "MPLS-TP"?

Fifth paragraph, either "Operations" should be "the Operations", or "function"

should be "functions" in the first sentence.

Sixth paragraph, "seperate ..." should be "separate ..."

section 5.1.1:

The first sentence is actually two separate sentences joined by a comma.  It

should just be two separate sentences.  Also, why is there a line-break before

"for" in the second line of the first paragraph?

The first sub-bullets under each of the two major bullets in this section should

include a reference to the identifiers draft (for  Global_ID, Node_ID and tunnel

LSR identifier).  I believe the intention is that "tunnel LSR identifier" should be

"Tunnel_ID"; if that is not correct, what does it mean?

section 5.1.2:

It is not obvious how the recommendations in this section address the issue

of all missing identifiers mentioned in the preceding section.  Which bullet is

intended to address the missing tunnel identfier based on ICC?

Section 5.2.1:

Again there is a mssing reference to the identifiers draft. Rather than add (or

repeat) these references, perhaps it would be better if a general statement

about identifiers was made in the lead-in text for section 5, along with current

references to various MIB documents, management and OAM requirements

and framework documents, etc.

Note that the first mention of the identifiers draft does not occur in this section

until sub-section 5.6.1 (even though material from this draft is needed earlier).

Section 5.4.1:

MIB-based management of exclusively on-demand OAM functions does not

make as much sense as for other OAM functions. In particualr, Route Tracing

does not seem to be an OAM function for which MIB-based management will

make any sense.

Some reasons why:

1) most MIBs today are essentially read-only.  Thus it is unlikely that a Route

    trace would be invokable via a MIB .

2) the results of a route-trace would be difficult to represent in a MIB.

3) a Route-Trace is very unlikely to be an ongoing activity that would need to

   be monitored over any significant period of time.

As near as I can tell, this is the only listed OAM function which is extremely

unlikely to be used in proactive OAM and - therefore - does not make sense

as a MIB function.

Section 6:

Second paragraph -

    "must be suppor in" should be "must be supported in"

Also, same paragraph -

    "need tbe conformed to" should be "need to be complied with"

Section 6:

Either there is a convention being employed here that I am not aware of,

or the phrase "New X" is being used in some way that is not transparent.

At several points in this section phrases like "new textual convention mib

module" and "New Identifiers" are used as if they are names of existing

documents, that already accomplish some goal described in susequent

text.

If the intention is to refer to a task that is as yet to be accomplished by a

new document, then the status of the task in question is not that it has

been done already, and the phrase should be prefixed with "a" (or "A" if

it occurs at the beginning of the sentence).  If these are names of a set

of documents, then these are very unfortunate names.

Section 6.1.2:

First paragraph - should "mib module" be "MIB module"?

Second paragraph - is there already a "new textual convention mib [SIC]

module" or are we getting ahead of ourselves in saying that a "textual

convention representing the MEP identifier is defined in new textual

convention mib [SIC] module"?

Same paragraph - "... identify maintenance ... should be "... identify a

maintenance ..."

Section 6.1.3:

I cannot be certain what this section says without understanding what

the convention ("New X") means, if anything.  Minimally, either the

sentence should start "A New identifier identifies a new managed ...",

"New identifiers identify new managed ...", or "New Identifiers describes

managed ..."

Section 6.1.4:

Second paragraph - "corouted" should be "co-routed"...

Section 6.1.5:

Second paragraph - "much similar" should be "very similar", or just "similar";

Also, is this MIB (MPLS-TE-STD-MIB) already extended (as the text implies),

or does it need to be extended?

Same paragraph - "could be" should be "are either" (they MUST be one or the

other, which is not what "could be X or Y" means).

Section 7 (Management Options):

Second paragraph - "refer" should be "refer to"...

Section 9 (IANA Considerations):

This is inconsistent with text earlier in the draft.  For example, in section 6.1.1,

6.2.1, 6.3.1 and 6.4.1, there is the statement that OIDs for MIB modules are yet

to be assigned and managed by IANA.

I think this is intended as a general statement, as it does not seem that this

document actually specifies any particular OIDs that would need to be assigned

by IANA (or, if it does, I did not pick up on it).  However, this document seems to

be making the point - possibly as a reminder - that the MIBs recommended by

this draft will require OID assignments from IANA.

I suggest saying something to this effect in the IANA considerations section and

adding that there is no IANA action required specifically by this document.  You

might easily modify the first two paragraphs in section 8 (Security Considerations)

for this purpose in Section 9.

You must do something to remove the current ambiguity, as it is not clear that

you are not requesting specific OIDs for the - as yet to be specified - new objects

in the OID trees in sections 6.1.1, 6.2.1, 6.3.1 and 6.4.1.

---

From: Eric Gray <[email-masked]>
Date: Tue, 21 Jun 2011 10:49:27 -0400

From: Eric Gray [mailto:[email-masked]]
Sent: Monday, June 20, 2011 2:12 PM
To: [email-masked]
Cc: [email-masked]
Subject: Last Call review of draft-ietf-mpls-tp-mib-management-overview-04

Comments/Questions
================

Introduction:

Section 1.1:

Section 4.2.6:

Section 4.2.8:

Section 4.2.10:

    MPLS-TE-STD-MIB and ...

Section 5:

section 5.1.1:

section 5.1.2:

Section 5.2.1:

Section 5.4.1:

Some reasons why:

Section 6:

Second paragraph -

Also, same paragraph -

Section 6:

Section 6.1.2:

Section 6.1.3:

Section 6.1.4:

Section 6.1.5: