Subject: [mpls] LC Comments for draft-ietf-mpls-tp-mib-management-overview-05.txt

From: "Daniel King" <[email-masked]>
Date: Sat, 20 Aug 2011 20:09:43 +0100

Hi All, 

Please find a breakdown of the LC comments addressed in the 05 version of
draft-ietf-mpls-tp-mib-management-overview. For a full set of diffs please
see:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-mib-management-overvie
w-05.txt

LC comments/initials:

- EC (Eric Gray)
- KC/OLS-315 (Kam Lam/ITU-T LS 315)
- DK (Daniel King/co-authors)

EG1>> Abstract: Why use "would be required" to describe additional MIB
modules?
Are they required, or does the requirement hinge on some other dependency?

DK>> Clarified text. Now reads "where additional MIB modules are required."
 
EG2>>Second paragraph: s/responsibility of the modules/responsibility for
the modules/
 
DK>> Fixed.

EG3>> 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.

DK>> Clarified text. Now reads "...LSPs and PWs."
 
EG4>> 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.

DK>> Used text suggested above.
 
EG5>> 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?
 
DK>> Clarified text. Now reads "...identifies areas where identifies areas
where additional MIB modules are be required."

EG6>> 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."

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).

KC/OLS-315>> Section 1.1: Should be "is separable". See RFC 5950 section
2.1, second paragraph.
 
DK>> Updated to read "The management of the MPLS-TP networks is separable
from that of its client networks so that the same means of management can be
used regardless of the client. The management function of MPLS-TP includes
fault management, monitoring, and security management." 

EG7>> 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?

DK>>Updated to read " The purpose of the management function is to provide
control and monitoring of the MPLS transport profile protocol mechanisms and
procedures."
 
EG9>> Section 2: PW terminology references are conspicuously missing from
this section.
Minimally, the PWE3 architecture (RFC 3985) should be included here.
 
DK>> Added reference to PWE3 architecture [RFC4805].

KC/OLS-315>> Section 4.2.2. Editorial: Should be Section 4.2.11

DK>> Fixed.

EG10>> 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.

DK>> Updated description: " Ingress and Egress LSRs of an LSP are known as
Label Edge Routers. An ingress LER takes the incoming unlabeled or labeled
packets and encapsulates it with the corresponding label of the LSP it
represents, and forwards it, over to the adjacent LSR of the LSP. Each FEC
is mapped to a label forwarding entry, so that packet could be encapsulated
with one or more label entries, referred as label stack.

The packet traverses across the LSP, and upon reaching the Egress LER,
further action will be taken to handle the packet, depending on the packet
it received. MPLS Architecture [RFC3031] details the functionality of an
Ingress and Egress LERs.

MPLS-FTN-STD-MIB [RFC3814] describes the managed objects for mapping FEC to
label bindings.

MPLS-LSR-STD-MIB [RFC3813] describes the required objects to define the
LSP."

EG11>> I suggest that you provide a definition "for the purposes of this
document" in the Terminology section.  

DK>>We (authors) felt this was unnecessary. 

EG12>> 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).
 
DK>> Updated text to read: "An LSP is a path over which a labeled packet
travels across the sequence of LSRs for a given FEC. When a packet, with or
without label, arrives at an ingress LER of an LSP, it is encapsulated with
the label corresponding to the FEC and sent across the LSP. The labeled
packet traverses across the LSRs and arrives at the egress LER of the LSP,
where, it gets forwarded depending on the packet type it came with. LSPs
could be nested using label stacking, such that, an LSP could traverse over
another LSP. 

A further description of    an LSP can be found in [RFC3031]."
 
EG13>> Section 4.2.6: In the first paragraph, why is there a line break
between "layered" and "modular"?

DK>> Fixed. 

EG14>> 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"?
 
DK>> Used suggested text.

KC/OLS-315>> Section 4.2.9: It will be helpful to give a pointer pointing to
the MIB module and RFC of this table. Same comment for the other tables
cited below in this section.

DK>> Added references. See
http://tools.ietf.org/html/draft-ietf-mpls-tp-mib-management-overview-05#sec
tion-4.2.9

EG15>> 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.
 
DK>> Updated diagram, please see:
http://tools.ietf.org/html/draft-ietf-mpls-tp-mib-management-overview-05#sec
tion-4.2.10

EG16>>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."

DK>>Updated to: " This section highlights 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
 
EG17>> Second paragraph, why is there a line-break between "of" and
"equipment"?

DK>> Fixed.
 
EG18>> Third paragraph, why is there a line-break between "for" and
"MPLS-TP"?
 
DK>> Fixed.

EG19>> Fifth paragraph, either "Operations" should be "the Operations", or
"function"
should be "functions" in the first sentence.
 
DK>> Fixed.

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

DK>> Fixed.
 
KC/OLS-315>> Section 5: What is the gap that this abstract model is trying
to address? Some clarification text could be helpful.

DK>> Removed text so no need for clarification. 

EG21>> 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?
 
EG22>> 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?
 
DK>> Comments above fixed with:

   - IP based environment
      i. MPLS-TE-STD-MIB [RFC3812] does not support tunnel
         Ingress/Egress identifier based on Global_ID and Node_ID
         [MPLS-TP-IDENTIFIERS].
      ii. MPLS-TE-STD-MIB [RFC3812] does not support
          co-routed/associated bidirectional tunnel configurations.

EG23>> 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?
 
DK>> New text added:

    - New MIB definitions may be created for Global_Node_ID and/or
      ICC configurations.

KC/OLS-315>> Section 5.1.2: The need to configure the next-hop MAC address
in IP-less environment is still undecided yet. It was described, as an not
preferred option, in the -01 data plane draft, but removed in the later
version and postponed to another document (still to be written). Suggestion:
s/can/could/

DK>> Clarified text: 

   - MPLS-LSR-STD-MIB [RFC3813] MIB modules may be enhanced to identify
      the nexthop based on MAC address for IP-less environments.
      OutSegment may be extended to hold the MAC-address also for
      IP-less environments.

EG24>> 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.

EG25>> 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).

DK>>  New txt added:

  [MPLS-TP-IDENTIFIERS] specifies an initial set of identifiers to be
   used in MPLS-TP. These identifiers were chosen to be compatible with
   existing MPLS, GMPLS, and PW definitions.
 
EG26>> 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.
 
DK>> Removed route tracing 

KC/OLS-315 & EG27>>  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"
 
DK>> Fixed.

EG28>> 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.

DK>> Fixed
http://tools.ietf.org/html/draft-ietf-mpls-tp-mib-management-overview-05#sec
tion-6.1

EG29>> Section 6.1.2: First paragraph - should "mib module" be "MIB module"?

DK>> Fixed.
 
EG30>> 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"?
 
DK>> Fixed to read "The textual convention representing the MEP identifier
should be defined in a new textual convention MIB module."

EG31>> Same paragraph - "... identify maintenance ... should be "...
identify a
maintenance ..."
 
DK>> Fixed.

EG32>> 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 ..."

DK>> Fixed and added reference. 
 
EG33>> Section 6.1.4: Second paragraph - "corouted" should be "co-routed"...

DK>> Fixed
 
EG34>> 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?

EG35>> 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).

DK>> Fixed.
http://tools.ietf.org/html/draft-ietf-mpls-tp-mib-management-overview-05#sec
tion-6.1.5
 
EG36>> Section 7 (Management Options): Second paragraph - "refer" should be
"refer to"...

DK>> Fixed
 
EG37>> 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.

DK>> Updated text to:

   This document has identified areas where additional MIB modules are
   neccessary for MPLS-TP. The new MIB modules recommended by this
   document will require OID assignments from IANA. However, this
   document makes no specific request for IANA action.