Subject: Re: [MIB-DOCTORS] MPLS TP TE MIB - Edited for review comments

From: Sam Aldrin <[email-masked]>
Date: Tue, 20 Nov 2012 14:36:58 -0800

Hi Joan and MIB doctors,

I am sure everyone is in the mood of thanksgiving.
Sincerely hope that this request doesn't cause any change in your plans for thanksgiving :D

Would appreciate if the document is reviewed and comments provided.
Hopeful to close all the issues and finalize the document, soon.

thanks in advance and happy thanksgiving.

cheers
-sam
On Oct 11, 2012, at 8:06 AM, Joan Cucchiara <[email-masked]> wrote:

> Sam,
>  
> Yes, I have been working on this MIB review and sorry for taking so long.
> Getting some interrupts ;)   but should be able to finish up within a week.
>  
> Thanks for your email,
>   -Joan
>  
> ----- Original Message -----
> From: Sam Aldrin
> To: Joan Cucchiara
> Cc: MIB Doctors (E-mail) ; Thomas Nadeau ; Venkatesan Mahalingam ; venkatesan mahalingam ; Kannan Sampath
> Sent: Wednesday, October 10, 2012 8:02 PM
> Subject: Re: MPLS TP TE MIB - Edited for review comments
> 
> Hi Joan and MIB doctors,
> 
> I hope you have gotten a chance to review the MIB document.
> Kindly let me know if you have any further comments.
> Will be glad to address them.
> 
> thanks in advance
> -sam
> On Sep 21, 2012, at 5:16 AM, Joan Cucchiara <[email-masked]> wrote:
> 
>> Sam,
>>  
>> Yes please include MIB Drs on these emails (I have forwarded your email to them).
>>  
>> I will take a look at the spreadsheet and MIB soon - hopefully next week.
>>  
>> Thanks for being so organized!
>>   -Joan
>>  
>>  
>>  
>> ----- Original Message -----
>> From: Sam Aldrin
>> To: Joan Cucchiara
>> Cc: Thomas Nadeau ; Venkatesan Mahalingam ; venkatesan mahalingam ; Kannan Sampath
>> Sent: Sunday, September 16, 2012 2:16 AM
>> Subject: MPLS TP TE MIB - Edited for review comments
>> 
>> Hi Joan,
>> 
>> How are you? thank you in advance for taking time to review the MIB draft. Appreciate very much.
>> Please find attachments of the following
>>   - New edited version of the draft
>>   - Excel sheet with all the comments listed and the status and comments for each of those
>>   - Emails regarding TP names from AD and WG chair (sent as separate email)
>>   - Changes from last version.
>> 
>> Some more details:
>> 
>> We have edited the MIB draft to address the comments. Some of the comments are not closed till we agree to resolve them with a common solution or point. They are listed as open in the XLS sheet. Otherwise most of the comments are addressed. Please do not take this as the document is complete with LC comments addressed. Only after all are addressed, we will take it to next level.
>> 
>> W.r.t TP within the MIB object names, I am not sure when we agreed to change. If we have done it, we might have misspoke. Reason why we do not want to change is as follows. When we initially started off the MIB, it had TP within every object name. But AD (Adrian Farell) and WG chair (Loa) have comeback and gave review comments to remove because MPLS TP is not another technology rather it is MPLS. And also, the objects could be used not only for TP but for bidirectional TE etc. Please find more details in the attached emails(actually forwarding separately) from them.
>> 
>> I haven't copied the email to MIB Dr's. If you want us to, we could do that.
>> 
>> Appreciate if you could review and give us your comments, within the XLS sheet or email. Either way is fine.
>> Also do let us know if we have missed any comments to track.
>> 
>> thanks in advance
>> -sam
>> 
>> p.s. I'll be out of country for the next 8 days and email access is sparse. <TP-TE-MIB-Comments.xls><draft-ietf-mpls-tp-te-mib-05.txt><Diff  draft-ietf-mpls-tp-te-mib-04.txt - draft-ietf-mpls-tp-te-mib-05.txt.htm>

---

From: "Joan Cucchiara" <[email-masked]>
Date: Wed, 21 Nov 2012 10:58:37 -0500

MIB Doctors,

I would like your guidance.

This draft proposes to add support of  Transport Profile (TP)
for MPLS-TC-STD-MIB [RFC3811], MPLS-LSR-STD-MIB [RFC3813]
and MPLS-TE-STD-MIB [RFC3812] c. 2004.

Essentially, the mplsTunnelTable from the MPLS-TE-STD-MIB [RFC3812]
could have entries created statically (i.e. manually by an operator) or
dynamically.  MPLS-TE Tunnels are uni-directional while MPLS-TE Tunnels
with Transport Profile are bi-direction (modelled as 2 uni-directional
tunnels which are related in the proposed new doc.)

I think the following 2 DESCRIPTIONs clauses are NOT the same semantically:

Original MplsExtendedTunnelId [RFC3811]:

       MplsExtendedTunnelId ::= TEXTUAL-CONVENTION
          STATUS        current
          DESCRIPTION
             "A unique identifier for an MPLS Tunnel.  This may
              represent an IPv4 address of the ingress or egress
              LSR for the tunnel.  This value is derived from the
              Extended Tunnel Id in RSVP or the Ingress Router ID
              for CR-LDP."
          REFERENCE
             "RSVP-TE: Extensions to RSVP for LSP Tunnels,
              [RFC3209].

              Constraint-Based LSP Setup using LDP, [RFC3212]."
          SYNTAX  Unsigned32(0..4294967295)

Here is the index's DESCRIPTION which uses the above TC.
To me, while syntactically equivalent are not
semantically equivalent, so this is
where I could use your guidance, please?

      mplsTunnelExtNodeConfigLocalId  OBJECT-TYPE
         SYNTAX        MplsExtendedTunnelId
         MAX-ACCESS    not-accessible
         STATUS        current
         DESCRIPTION
           "This object is used in accommodating the bigger
            size Global_Node_ID and/or ICC with lower size LSR
            identifier in order to index the mplsTunnelTable.

            The Local Identifier is configured between 0 and 16777215,
            as valid IP address range starts from 16777216(01.00.00.00).
            This range is chosen to identify the mplsTunnelTable's
            Ingress/Egress LSR-id is IP address or Local identifier,
            if the configured range is not IP address, operator is
            expected to retrieve the complete information
            (Global_Node_ID or ICC) from mplsTunnelExtNodeConfigTable.

            This way, existing mplsTunnelTable is reused for
            bidirectional tunnel extensions for MPLS based transport
            networks.

            This Local Identifier allows the operator to assign
            a unique identifier to map Global_Node_ID and/or ICC.
            As this Local Identifier is unique within the node and
            the same syntax of this object can be used for MPLS TE
            tunnel also, it is up to the operator/local management entity to
            choose the non-conflicting value for indexing the MPLS and
            MPLS-TP tunnel entries."
         ::= { mplsTunnelExtNodeConfigEntry 1 }

The above "guideline" range of "0" to "16777215" is supposed to be a
clue to operator  that this is an MPLS-TE Tunnel WITH Transport Profile,
HOWEVER, there is nothing in the original MIB that disallows operators from
manually configuring within this range.

One scenario (even if unlikely):
An MPLS TP with Transport Profile is configured dynamically,
which conflicts with an older legacy NMS which is statically configuring
MPLS TE Tunnel, and they both have chosen one of the same indexes (remember 
that there are
2 MplsExtendedTunnelId values for each tunnel.)   So again, while unlikely, 
seems that there is
potential conflict with legacy equipment.

I would like other MIB Doctor guidance:

Do you think (as I do) that the DESCRIPTION for
mplsTunnelExtNodeConfigLocalId (above) semantically redefines
the original MplsExtendedTunnelId TC?

Thank you,
  Joan

---

From: "Joan Cucchiara" <[email-masked]>
Date: Wed, 21 Nov 2012 11:24:16 -0500

Sam,

Thank you for your patience.   I have some comments
and some compiler output on the MIB.  I am going to hold
off on my detailed comments for the 
MPLS-LSR-EXT-STD-MIB and MPLS-TE-EXT-STD-MIB until the
MIB Doctors get a chance to give their guidance on the
issue MplsTunnelExtendedId's DESCRIPTION in the proposed draft.

Please note, that adding REFERENCE clauses which specify the section
may seem like a small issue, this would help me to review the draft.

Thank you and Happy Thanksgiving also,
  -Joan

General Issues which Apply to Entire Draft
--------------------------------------------

1) Naming....so I am okay with not including TP as part of the
MIB Module's name or Managed Objects.  I think it may be important to
explain why someplace (maybe in the Terminology Section).

2) Several places in this draft, the MIB Module is referred to
MPLS-TP MIB, please use the name of the MIB Module, especially since
you have made a point that you don't want to include the term, TP,
as part of the MIB Module's names or MO's names.

3) In general need more REFERENCES and more specific REFERENCES for TCs and 
OBJECTS.   Specifying an entire RFC is not very helpful.  
Please be more specific and include a section or subsection.

4) There are some compiler issues which are noted below for
each MIB Module.   I think these should be resolved.

5) Inconsistent use of RFC names.  For example in Section 3.2

"This document uses terminology from the MPLS architecture document
[RFC3031], MPLS Traffic Engineering Management information [RFC3812],
MPLS Label Switch Router MIB [RFC3813] and MPLS-TP Identifiers document
[RFC6370]."

Sometimes a very informal name for document title, sometimes part of
a title and sometimes the full title.  Please consistently give
the full title, so:
MPLS Label Switching Architecture [RFC3031], 
MPLS Label Switching (MPLS) Label Switching Router (LSR) Management
Information Base (MIB) [RFC3812] and so forth.

6) Similar to the above, please reference MIB Modules by the 
Module Name.  Someplaces do this, but some say MPLS Traffic Engineering MIB
or LSR MIB.  Again, please just be consistent.

For example:
Section 4. Motivations

As already mentioned in the above "General Issues Section"
Please clarify, "as the existing MIB" to something like
"as the existing MPLS-TE-STD-MIB" 

MPLS-ID-STD-MIB

*) MODULE's REVISION DESCRIPTION
          "MPLS identifiers MIB object extension"

What does this mean?  What exactly is the 'extension'?

*) Node_ID is assigned within the scope of the Global_ID, so can
Node_ID be derived from Global_ID ?   I'm wondering if this does need
to be read-write, or cannot it just be read-only based on what an
operator assigns to Global_ID?

*) There are only 3 scalars in this MIB Module and these are 
IMPORTED into the MPLS-TE-EXT-MIB Module, why are they not included
in the MPLS-TE-EXT-MIB?   In other words, why is there a separate
MIB Module for only 3 scalars?  (Certainly, this is a design choice
and I'm not saying this is incorrect, but am wondering what the benefit is?)

COMPILER OUTPUT
--------------------

MPLS-LSR-EXT-STD-MIB.my

SMICNG PRO
E: f(MPLS-LSR-EXT-STD-MIB.my), (195,10) Item "mplsInterfaceGroup" should be IMPORTed
W: f(MPLS-LSR-EXT-STD-MIB.my), (209,18) For "mplsXCExtTunnelPointer", syntax is identical
W: f(MPLS-LSR-EXT-STD-MIB.my), (208,18) MIN-ACCESS value identical to access specified for "mplsXCExtTunnelPointer"

MPLS-TE-EXT-STD-MIB.my

SMICNG PRO
E: f(MPLS-TE-EXT-STD-MIB.my), (108,7) Row "mplsTunnelExtNodeConfigEntry" may not have columns with MAX-ACCESS of read-write if any column is read-create
E: f(MPLS-TE-EXT-STD-MIB.my), (276,17) Index item "mplsTunnelExtNodeIpMapNodeId" must be defined with syntax that includes a range

  ----- Original Message ----- 
  From: Sam Aldrin 
  To: Joan Cucchiara 
  Cc: MIB Doctors (E-mail) ; Thomas Nadeau ; Venkatesan Mahalingam ; venkatesan mahalingam ; Kannan Sampath 
  Sent: Tuesday, November 20, 2012 5:36 PM
  Subject: Re: MPLS TP TE MIB - Edited for review comments

  Hi Joan and MIB doctors,

  cheers
  -sam

    Sam,

    Thanks for your email,
      -Joan

      ----- Original Message -----
      From: Sam Aldrin
      To: Joan Cucchiara
      Cc: MIB Doctors (E-mail) ; Thomas Nadeau ; Venkatesan Mahalingam ; venkatesan mahalingam ; Kannan Sampath
      Sent: Wednesday, October 10, 2012 8:02 PM
      Subject: Re: MPLS TP TE MIB - Edited for review comments

      Hi Joan and MIB doctors,

      thanks in advance
      -sam

        Sam,

        ----- Original Message -----
        From: Sam Aldrin
        To: Joan Cucchiara
        Cc: Thomas Nadeau ; Venkatesan Mahalingam ; venkatesan mahalingam ; Kannan Sampath
        Sent: Sunday, September 16, 2012 2:16 AM
        Subject: MPLS TP TE MIB - Edited for review comments

        Hi Joan,

        Some more details:

        thanks in advance
        -sam

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 21 Nov 2012 08:38:32 -0800

Thank you, Joan.
Really appreciate your comments.
Will track and will address each of those.

Have a happy Thanksgiving.

Cheers
Sam

Sent from my iPad

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 21 Nov 2012 16:38:06 -0800

Hi -

Although mplsTunnelExtNodeConfigLocalId adds more semantics to what
comes from MplsExtendedTunnelId, none of the constraints from the former
seem to be in conflict with the latter.  Consequently, I don't see a conflict
there.  It's perfectly reasonable for an object type to add constraints to a
textual convention it employs.

However, your comments make it sound as though the object type
mplsTunnelExtNodeConfigLocalId is an update to an existing object type.
If that is the case, and the earlier version lacks those constraints, that
could be of some concern, for the reasons you outline.

Randy

----- Original Message ----- 
> From: "Joan Cucchiara" <[email-masked]>
> To: "Sam Aldrin" <[email-masked]>
> Cc: "Venkatesan Mahalingam" <[email-masked]>; "MIB Doctors (E-mail)" <[email-masked]>; "venkatesan mahalingam"
<[email-masked]>; "Kannan Sampath" <[email-masked]>
> Sent: Wednesday, November 21, 2012 7:58 AM
> Subject: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt
>
>
> MIB Doctors,
>
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 21 Nov 2012 17:50:44 -0800

Hi Randy,

Thanks for the comments.

Yes, we are not updating the existing definition of the object type. We are not restricting the value of mplsTunnelExtNodeConfigLocalId  either, instead retains the same range as the original object type. We are open to suggestions to on modifications to the text. 

I hope this is ok with Joan as well.

-sam

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 21 Nov 2012 18:05:02 -0800

Hi -

> From: "Sam Aldrin" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: "Joan Cucchiara" <[email-masked]>; "Venkatesan Mahalingam" <[email-masked]>; "MIB Doctors (E-mail)"
<[email-masked]>; "venkatesan mahalingam" <[email-masked]>; "Kannan Sampath" <[email-masked]>
> Sent: Wednesday, November 21, 2012 5:50 PM
> Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt
...
> Yes, we are not updating the existing definition of the object type.

Thanks for he clarification.

> We are not restricting the value of mplsTunnelExtNodeConfigLocalId  either,
> instead retains the same range as the original object type.

Ok, here's where I think a possible source of confusion might be: when you
say "original object type" do you really mean "textual convention"?

> We are open to suggestions to on modifications to the text.

I don't have any problems with the text, though I haven't looked at it in the
depth that Joan has.  The object type definition  adds semantic constraints
to those already inherent in the TC.  That's perfectly fine, as long as those
constraints don't introduce a contradiction.

What you *might* consider is whether these additional constraints would
be needed anywhere else.  If that is the case, then it might be worthwhile
to define a new TC to capture that commonality.  But as it stands, I don't
have a problem with what you have.

> I hope this is ok with Joan as well.

She'll have to speak for herself.  :-)

Randy

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 21 Nov 2012 18:36:25 -0800

Hi Randy,

Thanks for the email.
Comments inline with %sam.

> say "original object type" do you really mean "textual convention"?
%sam - Correct. i.e. the TC of MplsExtendedTunnelId

> constraints don't introduce a contradiction.
%sam - nod.
> have a problem with what you have.
%sam - nod. AFAIK, there are no other places these constraints are needed.
> She'll have to speak for herself.  :-)

:D

thanks
-sam

---

From: "Joan Cucchiara" <[email-masked]>
Date: Mon, 26 Nov 2012 08:42:40 -0500

Randy,

Thank you for your very insightful comment.  Here is the original object 
(actually INDEX) DESCRIPTION from
rfc3812:

"mplsTunnelIngressLSRId OBJECT-TYPE
      SYNTAX        MplsExtendedTunnelId
      MAX-ACCESS    not-accessible
      STATUS        current
      DESCRIPTION
           "Identity of the ingress LSR associated with this
             tunnel instance. When the MPLS signalling protocol
             is rsvp(2) this value SHOULD be equal to the Tunnel

             Sender Address in the Sender Template object and MAY
             be equal to the Extended Tunnel Id field in the
             SESSION object. When the MPLS signalling protocol is
             crldp(3) this value SHOULD be equal to the Ingress
             LSR Router ID field in the LSPID TLV object."
      REFERENCE
           "1. RSVP-TE: Extensions to RSVP for LSP Tunnels,
             Awduche et al, RFC 3209, December 2001
            2. Constraint-Based LSP Setup using LDP, Jamoussi
             (Editor), RFC 3212, January 2002"
      ::= { mplsTunnelEntry 3 }

   mplsTunnelEgressLSRId OBJECT-TYPE
      SYNTAX        MplsExtendedTunnelId
      MAX-ACCESS    not-accessible
      STATUS        current
      DESCRIPTION
           "Identity of the egress LSR associated with this
             tunnel instance."
      ::= { mplsTunnelEntry 4 }"

My issue with the proposed draft's mplsTunnelExtNodeConfigLocalId (which is 
created as an INDEX, but also used as an OBJECT in the proposed draft) is 
that the value does NOT identify the Ingress/Egress of the MPLS Tunnel as in 
rfc3812.   The value of mplsTunnelExtNodeConfigLocalId is used to MAP the 
values of Ingress/Egress by a look-up in a new Table.

In other words, this value (mplsTunnelExtNodeConfigLocalId) is created so 
that the SYNTAX meets the criteria of the original, BUT the value is no 
longer a value which directly identifies an Ingress/Egress of an MPLS 
Tunnel.   The Ingress/Egress is only gotten via a look-up into a Mapping 
Table.    The reason that this is done is because the SYNTAX for an MPLS 
Tunnel with Transport Profile for Ingress/Egress is not even the same TYPE 
as the original MPLS Tunnel.

Thus, I conclude that this is a redefinition of the original definition 
because the original has the value of the MPLS Tunnel and the proposed 
mplsTunnelExtNodeConfigLocalId does NOT (again, the True value of the 
Ingress/Egress is in a lookup Table).

I can see all sorts of issues with legacy applications because these Tunnels 
would show up in the MplsTunnelTable and legacy apps would attempt to use 
the values as Ingress/Egress values for the tunnels on the Network, and they 
are NOT.

Thanks,
  -Joan

----- Original Message ----- 
From: "Randy Presuhn" <[email-masked]>
To: "Joan Cucchiara" <[email-masked]>; "Sam Aldrin" 
<[email-masked]>
Cc: "Venkatesan Mahalingam" <[email-masked]>; "MIB Doctors 
(E-mail)" <[email-masked]>; "venkatesan mahalingam" 
<[email-masked]>; "Kannan Sampath" <[email-masked]>
Sent: Wednesday, November 21, 2012 7:38 PM
Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance 
ondraft-ietf-mpls-te-tp-mib-05.txt

>> Cc: "Venkatesan Mahalingam" <[email-masked]>; "MIB Doctors 
>> (E-mail)" <[email-masked]>; "venkatesan mahalingam"

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 26 Nov 2012 07:54:02 -0800

Thanks, Joan and all.

Just to add few more points.

When the MIB extension was proposed to WG, we gotten feedback to with the proposed mode i.e. instead of redefining entirely new MIB, as the tunnels share same objects, use the same MIB with level of indirection. Having said that, vendors who have existing TE tunnel MIB implementations have already implemented this new MIB, without an issue. Supporting legacy TE tunnels with TP tunnels with the MIB was not at all an issue.

When we proposed to use 'non ip address' value for local index, is the very reason that the index is not referring to LSR Router ID. So, the applications cannot consider it as a valid router ID.

cheers
-sam
On Nov 26, 2012, at 6:29 AM, Kannan Sampath <[email-masked]> wrote:

> Hi Joan,
> Thanks Joan. You are on the dot.
> 
> I have an opinion regarding your point on "legacy applications ".
> If I assume that legacy applications are going to be used only with
> those legacy MPLS switches, we can also assume that new applications
> should be developed for supporting the MPLSTP systems.
> I mean, if we use "legacy application" for legacy MPLS tunnels and use
> "new application" for new MPLSTP tunnels, it should not be a problem I
> guess.
> If you can explain what kind of solution is required for such "legacy
> applications", we can try to provide better clarity on this.
> 
> Thanks & Regards,
> Kannan
> 
> 
> On Mon, Nov 26, 2012 at 7:12 PM, Joan Cucchiara
> <[email-masked]> wrote:
>> legacy applications