Subject: [mpls] MPLS-TP management overview draft - draft-farrel-mpls-tp-mib-management-overview

From: Eric Gray <[email-masked]>
Date: Wed, 7 Jul 2010 11:22:41 -0400

Authors,

    Some comments on your draft...

    As a general comment, in addition to the MIBs already explicitly referenced in this draft, you should probably
include:

o RFC 4801 ( "Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management " ),
o RFC 4802 ("Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base"),
o RFC 4220 ("Traffic Engineering Link Management Information Base");

As is, there is a curious dearth of MIB references for GMPLS related MIBs, given GMPLS will be the signaling
method used for MPLS-TP LSPs.

    NITs:
    ===

"functionss" is usually spelled with one "s" (page 7)

"exchaging" usually includes another "n" (page 7)

"MPLS packets are encapsulated by using its own header" doesn't
parse (page 7).  The second sentence in the same paragraph is just
barely more readable.  I would suggest re-writing the paragraph using
the phrase "label-stack" to replace "header."  This also eliminates the
need to identify the "header" as a "label-stack."

"path(" needs a space (page 8).

Change "The two important .." to "Two important ..." (page 8).  The
"two important applications" should be in bullet format.

"a MPLS" should be "an MPLS" anywhere that the indefinite article is
used in conjunction with "MPLS."

In the 5th paragraph on page 10, to what does "The document" refer?

Page 11 contains a number of examples where the first word following
a colon (":") is capitalized; this is not proper English - particularly when
the text following the colon is not in the form of a bulleted list.  I did not
check the entire draft for this, but suggest the authors should.

In the 2nd sentence, 7th paragraph of page 11, to what does "This MIB
module" refer?

The 2nd sentence in section 5.2.9 (top of page 13) does not parse.  I
suggest breaking this sentence down and clarifying what is meant by it.

The 2nd paragraph in section 5.2.10 (page 13) does not completely
describe the notation used.  An arrow indicates a dependency between
two MIB modules, but is clearly a directed dependency and meaning
is not clear: I suggest using a more illustrative example by making the
following change:

Change -
A relationship "MIB module A depends on MIB module B" means that
MIB module A uses an object, object identifier, or textual convention
defined in MIB module B, or that MIB module A contains a pointer
(index or RowPointer) to an object in MIB module B.
To -
The relationship "A --> B" means A depends on B and that MIB module
A uses an object, object identifier, or textual convention defined in MIB
module B, or that MIB module A contains a pointer (index or RowPointer)
to an object in MIB module B.
(Note that I am assumng I have the order of dependency correct, based
on conventional "logical dependency" - I did not verify this be analyzing
the diagram on page 14)

I suggest restructuring the last paragraph on page 16 (continuing on to
page 17) as two paragraphs, each including bulleted lists, as follows:

"The following MPLS-TP OAM functionalities can be achieved using the
 MPLSTP-OAM-STD-MIB mib extensions:

    o    Continuity Check and Connectivity Verification,
    o    Alarm Reporting, Diagnostic,
    o    Route Tracing,
    o    Loopback tool,
    o    Lock Instruct,
    o    Lock Reporting Remote Defect Indication,
    o    Client Failure Indication,
    o    Packet Loss Measurement and
    o    Packet Delay Measurement

"MPLS-TP OAM managed objects are defined based on the drafts:
    o    draft-ietf-mpls-tp-oam-requirements-06,
    o    draft-ietf-mpls-tp-oam-framework-06 and
    o    draft-ietf-mpls-tp-identifiers-01."

The last paragraph on page 17 (continuing on to page 18) has the same
problem as the 2nd paragraph on page 13 (described above) and needs
a similar resolution.  One approach might be to include this as part of a
new section (under modified section 2 "Conventions and Terminology"),
so that it does not need to be repeated.

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

    Not so NITty:
    =========

There are several problems with this paragraph (page 7):

"The basic unit in an MPLS network is called LSR(Label switched
  router). It implements the control and forwarding plane of MPLS."

o    as a NIT, "LSR(" needs a space;
o    the meaning of "basic unit" is not at all clear;
o    an LSR does not necessarily implement a control plane.
---------------------------------------------------------------------------------------------------------

The next paragraph is also inaccurate  (also page 7) .

The control plane of an LSR is not directly responsible for exchanging
routing information (that is the control plane of the "router" part of an
LSR, again not necessarily part of an LSR in the general sense).  This
"routing information" - if present - is simply one source of information
that an LSR uses to "program" (not the best wording choice - I suggest
"populate") forwarding tables.

The LSR "control plane" provides information in terms of label bindings
which are part of the information used to populate forwarding tables in
an LSR.  An LSR determines which label bindings to seek and retain
based on configuration and other information (such as that which may
be provided by routing).

While the primary intent (and common implementation) relies on use of
the 20 bit label as an "index into a forwarding table", this is not the only
way that an LSR may be implemented, nor is it necessarily presumed
to be implemented this way.  This misconception is at the bottom of a
number of bad ideas that have been proposed in the MPLS WG (as well
as other places).  How an LSR chooses to employ the 20 bit labels it
assigns for use by its peers is entirely up to the implementation.

---------------------------------------------------------------------------------------------------------

The remaining paragraphs in the section are slightly inaccurate as well.

At "MPLS ingress", a "label stack" is prefixed.  In the simplest case, the
"label stack" comprises a single label-stack entry.

At LSP ingress (because of the possibility of nested - or hierarchical -
LSPs), there is the possibility that one or more additional label-stack
entries will be "pushed" onto the label stack - if there is a label stack
present already. Otherwise, the paragraph above applies.

In at least the first case, there is more to "encapsulating" the packet
than simply prefixing an MPLS label (stack).  It is also necessary to
add the appropriate "MPLS-specific" L2 encapsulation (including, for
instance, the MPLS PID).

For all "swap", "pop" and "push" operations, one or more labels may
be involved.

---------------------------------------------------------------------------------------------------------

I believe the last paragraph in section 5.2.6 (on page 12) is inaccurate.
A device that terminates an ATM pseudo-wire will almost certainly offer
an ATM interface to other devices (otherwise, what is the point of using
an ATM pseudowire?).  If it does, it will necessarily have to include that
interface as part of the ifTable.

In any case, inclusion of the last two sentence in the last paragraph of
section 5.2.6 is unnecessary and those sentences should be removed.

---------------------------------------------------------------------------------------------------------

In the Security Considerations section, in the 3rd paragraph, you point
out the potential issues with allowing write and create access.  In the
same paragraph, you then go on to say "allowed to access and GET"
MIB objects.  I suggest deleting "and GET" from this paragraph.

---------------------------------------------------------------------------------------------------------

In the IANA Considerations section, given this is an overview document,
I think you are safe in at least starting off with the basic "IANA has no
actions" text found in most IDs of this type.  It is fairly certain that this
will not change, so you might as well get it out of the way.

===
Eric

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 8 Jul 2010 15:43:31 -0400

Why are we including GMPLS-related MIBs in this?  I'd like to not confuse the fact that the basic version of TP is supposed to be static, and handled (managed) as such. If you do talk about GMPLS MIBs in there, then I'd like to be very clear that it is optional.

	--Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 8 Jul 2010 15:42:14 -0400

--Tom

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sun, 11 Jul 2010 13:12:07 -0400

Tom,

While MPLS-TP can be run in a static environment, there will be
dynamically signaled deployments as well. As such, Eric is correct
that GMPLS-related MIBs should be included in the draft. There should
probably be an additional sub-section in section 6 to say that the
applicability for GMPLS MIBs would be for networks that are using
dynamically signaled LSPs.

Cheers,
Andy

On Thu, Jul 8, 2010 at 3:42 PM, Thomas Nadeau <[email-masked]> wrote:
>
> Why are we including GMPLS-related MIBs in this?  I'd like to not confuse
> the fact that the basic version of TP is supposed to be static, and handled
> (managed) as such. If you do talk about GMPLS MIBs in there, then I'd like
> to be very clear that it is optional.
> --Tom
>
> Authors,
>
>     As a general comment, in addition to the MIBs already explicitly
> referenced in this draft, you should probably
> include:
>
> o RFC 4801 ( "Definitions of Textual Conventions for Generalized
> Multiprotocol Label Switching (GMPLS) Management " ),
> o RFC 4802 ("Generalized Multiprotocol Label Switching (GMPLS) Traffic
> Engineering Management Information Base"),

---

From: Thomas Nadeau <[email-masked]>
Date: Sun, 11 Jul 2010 18:28:03 -0400

I'm not disputing that; just ask that we are clearly separating things.

Sent from my iPhone

---

From: Eric Gray <[email-masked]>
Date: Sun, 11 Jul 2010 18:35:09 -0400

Tom,

	I would support the approach Andy suggests.  This is supposed
to be an overview for management in MPLS-TP networks - hence it must
at least touch on the set of reasonable possibilties we are aware of
at the present time.

--
Eric 

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]] 
Sent: Sunday, July 11, 2010 6:28 PM
To: Andrew G. Malis
Cc: Eric Gray; A S Kiran Koushik; Daniel King; Venkatesan Mahalingam; [email-masked]; [email-masked]
Subject: Re: [mpls] MPLS-TP management overview draft - draft-farrel-mpls-tp-mib-management-overview

Sent from my iPhone