Subject: [MIB-DOCTORS] Authors and MIB Drs. comments on draft-vkst-mpls-tp-te-mib-00.txt

From: "Joan Cucchiara" <[email-masked]>
Date: Sun, 8 May 2011 17:22:11 -0400

Authors and MIB Drs.,

This draft is currently being polled to become a WG document in the MPLS WG.
Poll ends on May 18th.

This draft contains a table:  mplsTunnelExtTable which
AUGMENTS the mplsTunnelTable in RFC3812.

The indexes are:
        INDEX {
              mplsTunnelIndex,
               mplsTunnelInstance,
               mplsTunnelIngressLSRId,
               mplsTunnelEgressLSRId
            }

The above indexes seem to be redefined in this draft (quoting from the
DESCRIPTION clause):

         "As per MPLS-TP Identifiers draft,  LSP_ID is

            Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID::
            Dst-Tunnel_Num::LSP_Num for IP operator and

            Src-ICC::Src-Tunnel_Num::Dst-ICC::Dst-Tunnel_Num::LSP_Num
            for ICC operator,

            mplsTunnelTable is reused for forming the LSP_ID as follows,

            Source Tunnel_Num is mapped with mplsTunnelIndex,
            Source node identifier is mapped with
            mplsTunnelIngressLSRId, Destination node identifier is
            mapped with mplsTunnelEgressLSRId LSP_Num is mapped with
            mplsTunnelInstance.

            Source Global identifier/ICC and Destination
            Global identifier/ICC are maintained in the
            mplsNodeConfigTable and mplsNodeConfigLocalNum is used to
            create an entry in mplsTunnelTable."

Additionally,  one now needs to first configure an entry in the 
mplsNodeConfigTable in this draft, then
one can create an entry in the mplsTunnelTable (RFC3812).

Adrian Farrel recently posted to MPLS his concerns about this draft also. 
He suggested that
the mplsTunnelExtTable in this draft was probably meant to have 
sparse-augments relationship to the
mplsTunnelTable.    While I would agree that this is probably the case, even 
with a
sparse-augments relationship, would the indexes redefined for TP be 
acceptable?   I think not, although,
do see an advantage for having all mpls-based Tunnels in one table.

I am posting to MIB DRs to see if they have suggestions/comments.

Thank you,
 -Joan

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, May 03, 2011 1:47 PM
Subject: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt

>
> Working Group,
>
> this is to start a two week poll on making
>
> draft-vkst-mpls-tp-te-mib-00.txt
>
> an mpls working group document.
>
> If you support the document becoming a working group document
> please respond to this poll with "yes/support"
>
> If you do not support the document becoming a working group
> document please respond to this poll with "no/do not support"
> and at the same time give the technical reasons why you are
> not supporting the document.
>
> If you have technical comments or in any other way want to
> discuss the document, please send these comments to the mpls
> working group mailing list, but with another subject than what
> is on this mail.
>
> The poll ends 2011-05-18.
>
> /Loa
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Venkatesan Mahalingam <[email-masked]>
Date: Mon, 9 May 2011 10:34:55 +0530

Hi All,

Yes, the mplsTunnelExtTable is meant for Sparse augmenting the mplsTunnelTable. i.e. Entries will exist in the mplsTunnelExtTable only for MPLS_TP tunnels
 that are based on global ID and Node ID and/or ICC-ID.
This mplsTunnelExtTable is similar to gmplsTunnelEntry specified in RFC4802.

We understand that gmplsTunnelTable is also sparse augmented only for gmpls Tunnels. We understand that RFC4802 is not doing any redefinition of the indices.
Similarly, mplsTunnelExtTable is not meant for redefining the indices.
mplsTunnelExtTable uses the same indices as mplsTunnelTable. Only the meaning of them is interpreted based on mpls-tp-identifier.
Is it possible to explain the reason behind your question "would the indexes redefined for TP be acceptable" ?

Cheers,
Venkat.
________________________________________
From: Joan Cucchiara [[email-masked]]
Sent: Monday, May 09, 2011 2:52 AM
To: [email-masked]; [email-masked]; Thomas D. Nadeau; Venkatesan Mahalingam; Kannan KV Sampath
Cc: [email-masked]; [email-masked]; Joan Cucchiara
Subject: Authors and MIB Drs.  comments on draft-vkst-mpls-tp-te-mib-00.txt

Authors and MIB Drs.,

The indexes are:
        INDEX {
              mplsTunnelIndex,
               mplsTunnelInstance,
               mplsTunnelIngressLSRId,
               mplsTunnelEgressLSRId
            }

Thank you,
 -Joan

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, May 03, 2011 1:47 PM
Subject: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt

> The poll ends 2011-05-18.

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

---

From: "Joan Cucchiara" <[email-masked]>
Date: Tue, 10 May 2011 20:53:20 -0400

Hi Venkat,

The meaning of the indices cannot be redefined.  rfc4802 does not redefine 
the indices of the
mplsTunnelTable.   Redefining indices is a semantic change which is not 
allowed
by the SMI, so to answer my question:  no, not acceptable.

Secondly, a network that has the mplsTunnelTable populated would (if they 
wanted TP)
probably add this MIB, so how do these tables work with mplsTunnelTable 
already populated?
Given the way that indices are created in this MIB, would like to see this 
explained.

One other comment related to the above, is that this draft does not  follow 
the
draft-ietf-mpls-tp-identifiers as closely as it could, and there is added 
complexity
in this draft:   two extra tables and maintenance of a supporting object 
called mplsNodeConfigLocalNum.
If I understand the draft correctly, it seems that mplsNodeConfigLocalNum 
objects become
one of the indices for the mplsTunnelTable?   I don't understand the 
advantage
for not following  the TP Identifier draft (draft-ietf-mpls-tp-identifier)
more closely, so would like to understand that.

Before seeing this draft adopted as a WG group document (and doing more 
revisions) would like to
see the mplsTunnelTable indices remain the same and not be redefined.   If 
this cannot be done,
then you may want to consider a specific table for TP tunnels.

Thanks,
  -Joan

----- Original Message ----- 
From: "Venkatesan Mahalingam" <[email-masked]>
To: "Joan Cucchiara" <[email-masked]>; <[email-masked]>; 
<[email-masked]>; "Thomas D. Nadeau" <[email-masked]>; 
"Kannan KV Sampath" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, May 09, 2011 1:04 AM
Subject: RE: Authors and MIB Drs. comments on 
draft-vkst-mpls-tp-te-mib-00.txt

Hi All,

Yes, the mplsTunnelExtTable is meant for Sparse augmenting the 
mplsTunnelTable. i.e. Entries will exist in the mplsTunnelExtTable only for 
MPLS_TP tunnels
 that are based on global ID and Node ID and/or ICC-ID.
This mplsTunnelExtTable is similar to gmplsTunnelEntry specified in RFC4802.

We understand that gmplsTunnelTable is also sparse augmented only for gmpls 
Tunnels. We understand that RFC4802 is not doing any redefinition of the 
indices.
Similarly, mplsTunnelExtTable is not meant for redefining the indices.
mplsTunnelExtTable uses the same indices as mplsTunnelTable. Only the 
meaning of them is interpreted based on mpls-tp-identifier.
Is it possible to explain the reason behind your question "would the indexes 
redefined for TP be acceptable" ?

Cheers,
Venkat.
________________________________________
From: Joan Cucchiara [[email-masked]]
Sent: Monday, May 09, 2011 2:52 AM
To: [email-masked]; [email-masked]; Thomas D. Nadeau; 
Venkatesan Mahalingam; Kannan KV Sampath
Cc: [email-masked]; [email-masked]; Joan Cucchiara
Subject: Authors and MIB Drs.  comments on draft-vkst-mpls-tp-te-mib-00.txt

Authors and MIB Drs.,

The indexes are:
        INDEX {
              mplsTunnelIndex,
               mplsTunnelInstance,
               mplsTunnelIngressLSRId,
               mplsTunnelEgressLSRId
            }

Thank you,
 -Joan

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, May 03, 2011 1:47 PM
Subject: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt

> The poll ends 2011-05-18.

"DISCLAIMER: This message is proprietary to Aricent and is intended solely 
for the use of the individual to whom it is addressed. It may contain 
privileged or confidential information and should not be circulated or used 
for any purpose other than for what it is intended. If you have received 
this message in error, please notify the originator immediately. If you are 
not the intended recipient, you are notified that you are strictly 
prohibited from using, copying, altering, or disclosing the contents of this 
message. Aricent accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including damage from 
virus."

---

From: Venkatesan Mahalingam <[email-masked]>
Date: Wed, 11 May 2011 07:44:38 +0530

Hi Joan,

Thanks for your explanation. Please find the attached MPLS-TP tunnel design document for more information on design points.

What we understand from your reply is that, some of the design items are not clear in draft.

So, shall we have a conf. call at your convenient time this week to discuss on the MPLS-TP tunnel mib design?

Looking forward to talking to you all soon.

Cheers,
TP-MIB-Authors
________________________________________
From: Joan Cucchiara [[email-masked]]
Sent: Wednesday, May 11, 2011 6:23 AM
To: Venkatesan Mahalingam; [email-masked]; [email-masked]; Thomas D. Nadeau; Kannan KV Sampath
Cc: [email-masked]; [email-masked]
Subject: Re: Authors and MIB Drs.  comments on draft-vkst-mpls-tp-te-mib-00.txt

Hi Venkat,

Thanks,
  -Joan

----- Original Message -----
From: "Venkatesan Mahalingam" <[email-masked]>
To: "Joan Cucchiara" <[email-masked]>; <[email-masked]>;

Hi All,

Cheers,
Venkat.

Authors and MIB Drs.,

The indexes are:
        INDEX {
              mplsTunnelIndex,
               mplsTunnelInstance,
               mplsTunnelIngressLSRId,
               mplsTunnelEgressLSRId
            }

Thank you,
 -Joan

---

From: "Joan Cucchiara" <[email-masked]>
Date: Wed, 11 May 2011 15:45:11 -0400

Venkat,

I appreciate your efforts to try and help me to understand more clearly.
Thank you.  However, at this stage of adopting this draft as a working group 
doc
or not, the redefinition of indices is a semantic change and not allowed by 
the SMI.
My preference as a working group member would be to change the draft
so that there are no semantic differences from the TCs as defined in 
rfc3811.
If that cannot be done, then perhaps defining a new Table and
new TCs would be a solution.

Here are the relevant, original TCs in rfc3811.

MplsTunnelIndex ::= TEXTUAL-CONVENTION
          STATUS        current
          DESCRIPTION
             "A unique index into mplsTunnelTable.
              For tunnels signaled using RSVP, this value
              should correspond to the RSVP Tunnel ID
              used for the RSVP-TE session."
          SYNTAX  Unsigned32 (0..65535)

       MplsTunnelInstanceIndex ::= TEXTUAL-CONVENTION
          STATUS        current
          DESCRIPTION
             "The tunnel entry with instance index 0
              should refer to the configured tunnel
              interface (if one exists).

              Values greater than 0, but less than or
              equal to 65535, should be used to indicate
              signaled (or backup) tunnel LSP instances.
              For tunnel LSPs signaled using RSVP,
              this value should correspond to the
              RSVP LSP ID used for the RSVP-TE
              LSP.

              Values greater than 65535 apply to FRR
              detour instances."
          SYNTAX  Unsigned32(0|1..65535|65536..4294967295)

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)

rfc3812  (MPLS-TE-STD-MIB) contains the mplsTunnelTable which is the one
that is going to be sparsely Augmented by this draft.   I have also included 
another
object which is used by mplsTunnelTable to aid in creating values for the 
mplsTunnelIndex:

mplsTunnelIndexNext OBJECT-TYPE
      SYNTAX        IndexIntegerNextFree (0..65535)
      MAX-ACCESS    read-only
      STATUS        current
      DESCRIPTION
          "This object contains an unused value for
           mplsTunnelIndex, or a zero to indicate
           that none exist. Negative values are not allowed,
           as they do not correspond to valid values of
           mplsTunnelIndex.

           Note that this object offers an unused value
           for an mplsTunnelIndex value at the ingress
           side of a tunnel. At other LSRs the value
           of mplsTunnelIndex SHOULD be taken from the
           value signaled by the MPLS signaling protocol.
          "
      ::= { mplsTeObjects 1 }

 INDEX {  mplsTunnelIndex,
               mplsTunnelInstance,
               mplsTunnelIngressLSRId,
               mplsTunnelEgressLSRId
            }
      ::= { mplsTunnelTable 1 }

   MplsTunnelEntry ::= SEQUENCE {
         mplsTunnelIndex              MplsTunnelIndex,
         mplsTunnelInstance           MplsTunnelInstanceIndex,
         mplsTunnelIngressLSRId       MplsExtendedTunnelId,
         mplsTunnelEgressLSRId        MplsExtendedTunnelId,

Draft-vkst-mpls-tp-te-mib-00.txt has the following:

 * First create a row in mplsNodeConfigTable with index 
mplsNodeConfigLocalNum

     mplsNodeConfigLocalNum  OBJECT-TYPE
       SYNTAX        Unsigned32 (0..65535)
       MAX-ACCESS    not-accessible
       STATUS        current
       DESCRIPTION
         "This object allows the administrator to assign a unique
          identifier to map operator or global identifier and node
          identifier."
       ::= { mplsNodeConfigEntry 1 }

* Then create relevant row in either the mplsNodeIpMapTable or the
   mplsNodeIccMapTable

    This will "map" values to the (index) mplsNodeConfigLocalNum
    (either mplsIpNodeMapLocalNum or mplsNodeIccMapLocalNum ).

*  Then create a row in the mplsTunnelTable which redefines the original TC 
values:

     mplsTunnelIndex is now: Source Tunnel_Num

     mplsTunnelInstance is LSP_Num   (I'm not sure that this is even the 
same SYNTAX
     as the original TC because there is not enough information in the draft 
to know for certain.)

     mplsTunnelIngressLSRId and  mplsTunnelEgressLSRId take on values of 
mplsNodeConfigLocalNum
     which is a completely different value than the original TC DESCRIPTION 
in rfc3811.

RFC2579, section 5. describes revising a TC.

   "It may be desirable to revise the definition of a textual convention
   after experience is gained with it.  However, changes are not allowed
   if they have any potential to cause interoperability problems "over
   the wire" between an implementation using an original specification
   and an implementation using an updated specification(s).  Such
   changes can only be accommodated by defining a new textual convention
   (i.e., a new name)."

I am concerned that this MIB will cause interoperability problems with an
implementation that supports the mplsTunnelTable as per rfc3811 and rfc3812,
due to the semantic changes proposed in this draft.

Thanks,
  -Joan

----- Original Message ----- 
From: "Venkatesan Mahalingam" <[email-masked]>
To: "Joan Cucchiara" <[email-masked]>; <[email-masked]>; 
Sent: Tuesday, May 10, 2011 10:14 PM

Hi Joan,

Thanks for your explanation. Please find the attached MPLS-TP tunnel design 
document for more information on design points.

What we understand from your reply is that, some of the design items are not 
clear in draft.

So, shall we have a conf. call at your convenient time this week to discuss 
on the MPLS-TP tunnel mib design?

Cheers,
TP-MIB-Authors
________________________________________
From: Joan Cucchiara [[email-masked]]
Sent: Wednesday, May 11, 2011 6:23 AM
To: Venkatesan Mahalingam; [email-masked]; [email-masked]; 
Thomas D. Nadeau; Kannan KV Sampath
Cc: [email-masked]; [email-masked]
Subject: Re: Authors and MIB Drs.  comments on 
draft-vkst-mpls-tp-te-mib-00.txt

Hi Venkat,

Thanks,
  -Joan

----- Original Message -----
From: "Venkatesan Mahalingam" <[email-masked]>
To: "Joan Cucchiara" <[email-masked]>; <[email-masked]>;

Hi All,

Cheers,
Venkat.

Authors and MIB Drs.,

The indexes are:
        INDEX {
              mplsTunnelIndex,
               mplsTunnelInstance,
               mplsTunnelIngressLSRId,
               mplsTunnelEgressLSRId
            }

Thank you,
 -Joan

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 11 May 2011 14:04:00 -0700

Hi Joan,
 
Thanks for all the emails, though it is not an ideal medium, to resolve the TP MIB issues.
Hopefully my reply will not create any further confusion, instead will try to explain what we think and see how we can go forward.
 
First of all, I would like to give a little background and how we designed in simple terms.
Secondly, I will answer to your concerns.
 
Motive:
--------
Creating a new MIB with brand new tables is all we wanted from the very beginning but having dealt with multiple MIBs in the past, that was the last thing we wanted from implementer’s perspective. So, we focused on re-using the existing MIB, in order for us to not to go through the re-definition of objects all over again. So, here we are :D
 
Design:
--------
MPLS-TP is subset of MPLS, so, the ideal choice was to re-use MPLS-TE MIB. Unfortunately, the table indices are not 1:1 match, due to the way TP tunnels are uniquely identified. As the tunnels share the same objects, it is not really useful to create a new table with different indices. So, we opted to map the TP tunnel identifier to the existing Tunnel indices.
 
In order to do that, we had issue with IngressLSRID and EgressLSRID. In the case of TE tunnels, we were using the router_id, which is a valid IP address. The values from 0 to 1.0.0.0 are not used. So, we decided to use that range for TP tunnel ingress and Egress LSR id’s.
 
What we did is, we took the MPLS TP identifier and derived the, so called, “localnumber” for a given MPLS TP identifier. Be it a source LSR or Egress LSR. This is local to the device and means nothing, outside of the device. Two other tables (read only tables) are added to do the reverse look up for the TP identifier from a given local number. Again it is local.
 
For TP specific objects, we augmented (sparse) the TE table, so that TP specific information could be queried.
 
Concerns:
1.       Interoperability due to localNum: This is one of the most discussed items, when we designed this MIB. As I mentioned, the localnumber is very local to the node and mean nothing, we do not perceive any interoperability issue. Also, the value is well within the non-valid IP address, which was deliberately choosen, so that it doesn’t interfere with TE Tunnels, which could already be present. But if you think of any other interoperability scenarios, which could cause an issue, please state it. We would be glad to hear it and see if that is something we could overcome or not.
2.       Redefinition of the TC: It is true that the definition is changed as per the needs. As the TC itself says, “may represent ipv4”, and we are using non-ipv4, we differ from TC definition. What we could is to enhance the TC or change it or do whatever is needed. This is minor change and shouldn’t cause any problem. As you pointed out in RFC2579, the TC could be redefined, upon experience gained, and I do see TP is a good case for that.
 
I hope this clarifies your concerns. Please do let us know if you still have concerns, I would like to have a call setup for tomorrow, so we can discuss over the phone, instead of email.
 
Appreciate your time in looking into this.
 
Cheers
-sam

Sent from my iPad

On May 11, 2011, at 12:45 PM, "Joan Cucchiara" <[email-masked]> wrote:

> Thank you.  However, at this stage of adopting this draft as a working group doc
> or not, the redefinition of indices is a semantic change and not allowed by the SMI.
> so that there are no semantic differences from the TCs as defined in rfc3811.
> that is going to be sparsely Augmented by this draft.   I have also included another
> object which is used by mplsTunnelTable to aid in creating values for the mplsTunnelIndex:
> 
> * First create a row in mplsNodeConfigTable with index mplsNodeConfigLocalNum
> 
> *  Then create a row in the mplsTunnelTable which redefines the original TC values:
> 
>    mplsTunnelInstance is LSP_Num   (I'm not sure that this is even the same SYNTAX
>    as the original TC because there is not enough information in the draft to know for certain.)
> 
>    mplsTunnelIngressLSRId and  mplsTunnelEgressLSRId take on values of mplsNodeConfigLocalNum
>    which is a completely different value than the original TC DESCRIPTION in rfc3811.
> 
> ----- Original Message ----- From: "Venkatesan Mahalingam" <[email-masked]>
> To: "Joan Cucchiara" <[email-masked]>; <[email-masked]>; <[email-masked]>; "Thomas D. Nadeau" <[email-masked]>; "Kannan KV Sampath" <[email-masked]>
> Subject: RE: Authors and MIB Drs. comments on draft-vkst-mpls-tp-te-mib-00.txt
> 
> 
> Hi Joan,
>

---

From: Kannan KV Sampath <[email-masked]>
Date: Thu, 12 May 2011 17:32:13 +0530

Hi Joan,

We guess that your prime concern is about Textual Convention and values.

We thought that the following analysis would help in resolving the conflict in TC.

Please have a look on this email reply tagged with “<<KVSK>>” and let us know your views.

>>mplsTunnelIndex is now: Source Tunnel_Num

<<KVSK>> According to us, the values for mplsTunnelIndex and SourceTunnelNum can remain same. The “Description” for them differs, but, there is no change in the values. We assume that TC is more strict w.r.t Values, but not the description and the way they should be interpreted inside the MIB. With this assumption, can we assume that Index1 is fine and there is no conflict with TC for mplsTunnelIndex?

>>   as the original TC because there is not enough information in the draft to know for certain.)

<<KVSK>> According to us, the values can remain same. So, there is no change. Can we assume that Index2 is also fine & there is no conflict w.r.t TC?

>>   which is a completely different value than the original TC DESCRIPTION in rfc3811.

<<KVSK>>

Problem Statement:

We do have a conflict in them; mplsTunnelIngressLSRId and mplsTunnelEgressLSRId is based on MplsExtendedTunnelId TC. They take value from 0 to 4294967295; but mplsNodeConfigLocalNum is having a different SYNTAX and different range 0 to 65535.

The mplsNodeConfigLocalNum is currently having the following syntax.

Reason behind this value conflict:

We have restricted the value to 65535, just because we wanted to differentiate the MPLS_TP entries based on this range of values.

i.e If the IngressLsrId is less than this 65535 (This 65535 can be changed to a different value 16777215 - the first valid IP address being 1.0.0.1), it is easy to differentiate this tunnel entry as MPLT_TP tunnel.

Proposed Change:

To solve this conflict in values, we would like to propose the following change.

If we add a new tunnel_type object in the MIB (this object will be used to differentiate MPLS tunnel and MPLS_TP tunnel), we can remove this restriction on the value for mplsNodeConfigLocalNum. If this logic (for differentiating the MPLS tunnel and MPLS_TP tunnel) is acceptable, we can change the syntax for mplsNodeConfigLocalNum as same as mplsTunnelIngressLSRId.

If we change this SYNTAX (for mplsNodeConfigLocalNum) as "MplsExtendedTunnelId", is the problem that you have mentioned solved?

Thanks & Regards,

Kannan.

From: Sam Aldrin [mailto:[email-masked]]
Sent: Thursday, May 12, 2011 2:34 AM
To: Joan Cucchiara
Cc: Venkatesan Mahalingam; <[email-masked]>; Thomas D. Nadeau; Kannan KV Sampath; <[email-masked]>; <[email-masked]>
Subject: Re: Authors and MIB Drs. comments on draft-vkst-mpls-tp-te-mib-00.txt

Hi Joan,

Motive:
--------

Design:
--------

Concerns:

Cheers
-sam

Sent from my iPad

On May 11, 2011, at 12:45 PM, "Joan Cucchiara" <[email-masked]<mailto:[email-masked]>> wrote:

Venkat,

INDEX {  mplsTunnelIndex,
             mplsTunnelInstance,
             mplsTunnelIngressLSRId,
             mplsTunnelEgressLSRId
          }

Thanks,
-Joan

----- Original Message ----- From: "Venkatesan Mahalingam" <[email-masked]<mailto:[email-masked]>>
To: "Joan Cucchiara" <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>; "Thomas D. Nadeau" <[email-masked]<mailto:[email-masked]>>; "Kannan KV Sampath" <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, May 10, 2011 10:14 PM
Subject: RE: Authors and MIB Drs. comments on draft-vkst-mpls-tp-te-mib-00.txt

Hi Joan,

Cheers,
TP-MIB-Authors
________________________________________
From: Joan Cucchiara [[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, May 11, 2011 6:23 AM
To: Venkatesan Mahalingam; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Thomas D. Nadeau; Kannan KV Sampath
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Authors and MIB Drs.  comments on draft-vkst-mpls-tp-te-mib-00.txt

Hi Venkat,

Thanks,
-Joan

----- Original Message -----
From: "Venkatesan Mahalingam" <[email-masked]<mailto:[email-masked]>>
To: "Joan Cucchiara" <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>;
<[email-masked]<mailto:[email-masked]>>; "Thomas D. Nadeau" <[email-masked]<mailto:[email-masked]>>;
"Kannan KV Sampath" <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>
Sent: Monday, May 09, 2011 1:04 AM
Subject: RE: Authors and MIB Drs. comments on
draft-vkst-mpls-tp-te-mib-00.txt

Hi All,

Cheers,
Venkat.
________________________________________
From: Joan Cucchiara [[email-masked]<mailto:[email-masked]>]
Sent: Monday, May 09, 2011 2:52 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Thomas D. Nadeau;
Venkatesan Mahalingam; Kannan KV Sampath
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Joan Cucchiara
Subject: Authors and MIB Drs.  comments on draft-vkst-mpls-tp-te-mib-00.txt

Authors and MIB Drs.,

The indexes are:
      INDEX {
            mplsTunnelIndex,
             mplsTunnelInstance,
             mplsTunnelIngressLSRId,
             mplsTunnelEgressLSRId
          }

Thank you,
-Joan

----- Original Message -----
From: <[email-masked]<mailto:[email-masked]>>
To: <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, May 03, 2011 1:47 PM
Subject: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt

Working Group,

/Loa

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

________________________________
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

---

From: "Joan Cucchiara" <[email-masked]>
Date: Mon, 16 May 2011 09:12:55 -0400

Kannan and Sam,

While the draft may be wanted for a proprietary MIB,  I think 
that it should NOT become an IETF MIB (i.e. not adopted by the
MPLS WG as a WG document) with the current design because:

1) (as I've already said) the draft's design proposes semantic changes 
to TCs in the MPLS-TC-STD-MIB which is not allowed according to rfc2579.   

(Please note, I am not debating whether or not this draft works in your 
environment, however,  I have serious doubts that this would work in many networks
given that the MPLS-TC-STD-MIB and MPLS-TE-STD-MIB became rfcs in 2004 and
have been implemented in networks since about that timeframe, so there is a lot 
of legacy.)

2)  The goal of representing MPLS-TP Tunnels in a MIB can be
achieved in a far more standards-based design.  As an example, 
create new TCs and a new TP Tunnel Table which is also suggested by Adrian. 
 Admittedly, this example does not change the mplsTunnelTable from rfc3812 
and thus, the mplsTunnelTable would not contain MPLS-TP Tunnels.  
However, displays (GUIs, CLIs, etc) could  certainly show MPLS Tunnels 
and MPLS-TP tunnels together, if wanted, thus giving you a similar outcome.  

Thanks,
  -Joan

  ----- Original Message ----- 
  From: Kannan KV Sampath 
  To: Joan Cucchiara 
  Cc: Venkatesan Mahalingam ; <[email-masked]> ; Thomas D. Nadeau ; <[email-masked]> ; <[email-masked]> ; Sam Aldrin 
  Sent: Thursday, May 12, 2011 8:02 AM
  Subject: RE: Authors and MIB Drs. comments on draft-vkst-mpls-tp-te-mib-00.txt

  Hi Joan,

  <<KVSK>> 

  Problem Statement:

  Proposed Change:

  Thanks & Regards,

  Kannan.

  Hi Joan,

  Motive:

  --------

  Design:

  --------

  Concerns:

  Cheers

  -sam

  Sent from my iPad

    Venkat,

    INDEX {  mplsTunnelIndex,
                 mplsTunnelInstance,
                 mplsTunnelIngressLSRId,
                 mplsTunnelEgressLSRId
              }

    Thanks,
    -Joan

    Hi Joan,

    Cheers,
    TP-MIB-Authors

    Hi Venkat,

    Thanks,
    -Joan

    ----- Original Message -----
    From: "Venkatesan Mahalingam" <[email-masked]>
    To: "Joan Cucchiara" <[email-masked]>; <[email-masked]>;
    <[email-masked]>; "Thomas D. Nadeau" <[email-masked]>;
    "Kannan KV Sampath" <[email-masked]>
    Cc: <[email-masked]>; <[email-masked]>
    Sent: Monday, May 09, 2011 1:04 AM
    Subject: RE: Authors and MIB Drs. comments on
    draft-vkst-mpls-tp-te-mib-00.txt

    Hi All,

    Cheers,
    Venkat.

    Authors and MIB Drs.,

    The indexes are:
          INDEX {
                mplsTunnelIndex,
                 mplsTunnelInstance,
                 mplsTunnelIngressLSRId,
                 mplsTunnelEgressLSRId
              }

    Thank you,
    -Joan

    ----- Original Message -----
    From: <[email-masked]>
    To: <[email-masked]>
    Cc: <[email-masked]>; <[email-masked]>
    Sent: Tuesday, May 03, 2011 1:47 PM
    Subject: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt

      Working Group,

      is on this mail.

      /Loa

      mpls mailing list

      [email-masked]

------------------------------------------------------------------------------
  "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."