Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt

From: Randy Presuhn <[email-masked]>
Date: Mon, 26 Nov 2012 11:27:56 -0800 (GMT-08:00)

Hi -

Much good stuff deleted, but before going further,
let me see whether I understand the situation correctly.
  Old MIB has table T1 indexed by I1.
  New MIB has table T2 indexed by I2, and 
  a mapping table M associating I1 and I2,
  allowing management software to do a "join"
  as needed of information from the tables.

If that is what they are doing, I don't see a MIB problem,
as long as the mapping table works to keep the number of
queries reasonable for high-frequency use cases.

There's no rule requiring that an indexing structure used
in a MIB associated with a particular technology be re-used
in all future MIBs related to that technology.  One would
hope that the initial index structure would anticipate
future needs and developments, but there's no requirement
to do so.

It sounds to me that your concern is that implementors will
confuse I1 and I2, despite the differing semantics. If so,
I think the concern might by assuaged by an analogy.

Consider a hypothetical MIB with an index I'll call fooName,
with a UTF-8 string textual convention as its syntax.  Its
description says it's a person's name, without further elaboration.
(Why am I reminded of my old co-worker named "Tyler Martin"
and my friend "Lee, Nielson"? :-)  Later, another MIB, in order
to meet specific requirements may well introduce an index I'll
call fooLastCommaFirstName, with a description specifying that
is constructed from a family name, a comma, and a list of
given names separated by spaces.    The difference in the
semantics of these indexes is purely in their respective
description clauses, yet we don't worry about implementors
confusing them.

Obviously not ideal (it's a source of possible user confusion),
but certainly not *wrong*, and if it supports important use cases
the original ones did not, it's still the right thing to do,
especially if the new index structure supports use cases that
the old one would not.  (E.g. access control, partial table
retrieval, clustering of related entries, etc., etc.)

Randy

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 26 Nov 2012 16:28:38 -0800

Thanks, Randy for the detailed email with analogy.
You pretty much captured the essence of what we are trying to do.

Joan, is there something we might be missing here, that should be addressed in this regard?

Thank you, Joan and Randy, for your valuable comments, which are of often overlooked by MIB developers like me.
Much appreciated.

cheers
-sam

---

From: "Joan Cucchiara" <[email-masked]>
Date: Tue, 27 Nov 2012 00:08:03 -0500

----- 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: Monday, November 26, 2012 2:27 PM
Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance 
ondraft-ietf-mpls-te-tp-mib-05.txt

> description clauses, yet we don't worry about implementors

Randy,

Thanks for the great example!

So to carry this example a step further, then the M (mapping) Table in the 
new MIB associates I1 and I2.  So for example,
I1 has a value of "John Doe"  (fooName) and the new MIB has I2 with a value 
of  "Doe, John" (fooLastCommaFirstName)
and an entry is created in M which associates  "JohnDoe" with "Doe, John". 
Is this correct?

The draft is doing something different.   Using your example above, the 
draft proposes the following steps, which MUST be in this order:

* Create an entry in T2 with I2  in the new MIB.  (T2 is the mapping table, 
M, which maps I2 to the actual ID for the Tunnel with TP).
* Create an entry in T1 using I2 as the index.   (There is no I1.)
*  Create additional entries in a few tables in the new draft  ('reverse' 
mapping tables, and also a table which associates the T1 entry to a second 
T1 entry which is how bi-directional tunnels are represented in the new 
draft.  Bi-directional tunnels are for TP and did not exist in the original 
MIB.)

The original Tunnels represented in T1 were of type Unsigned32 and 
represented a value that was meaningful on the network.
The new Tunnels with TP are either "Global Id" of  OCTET (SIZE 4) , or "ICC 
Id" of OCTET (SIZE 6).

Since the new Tunnels with TP, share the same objects (but NOT the index) as 
the original Tunnels represented in rfc3812, then the goal is to use the 
original  T1.  The "gotcha" is that the original MIB is indexed by 
Unsigned32 value which was unique and meaningful on the network BUT this 
index (I1) has no meaning wrt these new Tunnels with TP.  The new tunnels 
are identified by Global Id (OCTET STRING (SIZE 4)) or Icc Id (OCTET STRING 
(SIZE 6)).

So the solution being proposed is to create an entry  in T2 with I2 (again 
T2 IS the M (mapping table)), and then create an entry in T1 which MUST use 
I2 as the index.

Keeping in mind that I1 is value which is unique and meaningful on the 
network, and what is being proposed is just a value within Unsigned32 range, 
but doesn't appear anywhere on the network, may cause some confusion for 
legacy apps.
An analogy would be to create a T2 which is in the correct format, but is 
not identifiable as a name.

I think your example was quite helpful in highlighting some important 
details.

Thanks,
  -Joan

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 26 Nov 2012 21:52:15 -0800

I have couple of comments inline with %sam.

Sam

Sent from my iPad

On Nov 26, 2012, at 9:08 PM, "Joan Cucchiara" <[email-masked]> wrote:

> 
> ----- 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]>
> Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt
> 
> 
>> Hi -
>> 
> So to carry this example a step further, then the M (mapping) Table in the new MIB associates I1 and I2.  So for example,
> I1 has a value of "John Doe"  (fooName) and the new MIB has I2 with a value of  "Doe, John" (fooLastCommaFirstName)
> and an entry is created in M which associates  "JohnDoe" with "Doe, John". Is this correct?
> 
> The draft is doing something different.   Using your example above, the draft proposes the following steps, which MUST be in this order:
> 
> * Create an entry in T2 with I2  in the new MIB.  (T2 is the mapping table, M, which maps I2 to the actual ID for the Tunnel with TP).
> *  Create additional entries in a few tables in the new draft  ('reverse' mapping tables, and also a table which associates the T1 entry to a second T1 entry which is how bi-directional tunnels are represented in the new draft.  Bi-directional tunnels are for TP and did not exist in the original MIB.)
%sam- having bi-directional tunnels could be associated or congruent. So, it is not necessary that there is always entry will be present all the time.
Also, there is an effort to bring TP technologies in to TE land. In that case, the existing MIB has to be redone. This change being proposed will help when that happens as well.
> 
> The original Tunnels represented in T1 were of type Unsigned32 and represented a value that was meaningful on the network.
> The new Tunnels with TP are either "Global Id" of  OCTET (SIZE 4) , or "ICC Id" of OCTET (SIZE 6).
> 
> Since the new Tunnels with TP, share the same objects (but NOT the index) as the original Tunnels represented in rfc3812, then the goal is to use the original  T1.  The "gotcha" is that the original MIB is indexed by Unsigned32 value which was unique and meaningful on the network BUT this index (I1) has no meaning wrt these new Tunnels with TP.  The new tunnels are identified by Global Id (OCTET STRING (SIZE 4)) or Icc Id (OCTET STRING (SIZE 6)).
%sam - which is the reason why mapping table is still needed whether old tunnel table or new tunnel table is used.
> 
> So the solution being proposed is to create an entry  in T2 with I2 (again T2 IS the M (mapping table)), and then create an entry in T1 which MUST use I2 as the index.
> 
> Keeping in mind that I1 is value which is unique and meaningful on the network, and what is being proposed is just a value within Unsigned32 range, but doesn't appear anywhere on the network, may cause some confusion for legacy apps.
%sam - the value of l1, though unique, having non-ip address value mean nothing, even to the legacy application. That is why, re-using the table with non-ip value is a perfect choice.
As Randy said in his earlier email, this model of reusing the index is not against the rule, it should be perfectly fine. 

Cheers
Sam

> An analogy would be to create a T2 which is in the correct format, but is not identifiable as a name.
> 
> I think your example was quite helpful in highlighting some important details.
> 
> Thanks,
> -Joan
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 26 Nov 2012 22:07:32 -0800

Hi -

> From: "Joan Cucchiara" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "Sam Aldrin" <[email-masked]>
> Cc: "Venkatesan Mahalingam" <[email-masked]>; "MIB Doctors (E-mail)" <[email-masked]>; "venkatesan mahalingam"
> Sent: Monday, November 26, 2012 9:08 PM
...
> and an entry is created in M which associates  "JohnDoe" with "Doe, John".

Yes.  "Smith, Mary" <-> "Smith, Mary" is also possible, BTW.
*How* mapping M is maintained is a bit of magic.  For example,
mappings like "Pookie" <-> "Howell, Thurston III" are possible
as well, at least in concept. :-)

> * Create an entry in T1 using I2 as the index.   (There is no I1.)

Uh, I think what they mean here is "Create an entry in T1, using for
the value of I1 whatever the value of I2 happens to be, assuming that
the normal operation of the system will avoid collisions."

> represented a value that was meaningful on the network.

I missed the part about "a value that was meaningful on the network"
in the earlier discussion.  To which entities in the network would
a given value have the same meaning?

> The new Tunnels with TP are either "Global Id" of  OCTET (SIZE 4) , or "ICC

These are two completely different data types, so confusion should
not be an issue...

> Unsigned32 value which was unique

unique within what scope?

> and meaningful on the network

which network?  globally?

> BUT this

Again, a nit: if the mapping is simple identity, then it's not T1 *using* I2.
T1 still uses I1.  What *is* being imposed are some assumptions about how
the set of values for I2 is allocated.  Specifically, when value is assigned
for I2, there's a strong assumption that that value will not collide with
another use of that same value in the set of values taken by I1 in that
implementation.

At this point, it sounds like they're on a potentially risky path.
Not necessarily broken, but one that demands careful thought and
documentation of the operational assumptions.

> but doesn't appear anywhere on the network, may cause some confusion for

Now this seems to be a quite different understanding of the semantics
of the indexes from what I've gleaned from the conversation so far.
In particular, up to this point it seemed that the "old" index was
*less* semantically constrained, at least as far was the description
clauses went.

> not identifiable as a name.

How would something be "not identifiable as a name"?  My
experience is that if someone says something is their name,
there's no point in contradicting them.  Consequently, I
have trouble with the concept "not identifiable as a name".
Saying that something is "a name" gives us an idea what it
means, but doesn't provide any help in limiting the set
of possible values.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 26 Nov 2012 22:20:59 -0800

Hi -

> From: "Sam Aldrin" <[email-masked]>
...
> *  Create additional entries in a few tables in the new draft 
> ('reverse' mapping tables, and also a table which associates
> the T1 entry to a second T1 entry which is how bi-directional
> tunnels are represented in the new draft.  Bi-directional tunnels
> are for TP and did not exist in the original MIB.)

%sam- having bi-directional tunnels could be associated or
 congruent. So, it is not necessary that there is always entry
 will be present all the time.
 Also, there is an effort to bring TP technologies in to TE land.
 In that case, the existing MIB has to be redone. This change
 being proposed will help when that happens as well.

Suggestion - if you haven't already done so, it might be
helpful to document (in the form of examples) what the
most important cases would look like in terms of index
structure, giving at least some thought to what things
might look like if someone looks at the MIB while a tunnel
is still under construction. (This usually entails carving out
an index value for "none" or talking about what a reference
to a nonexistent row means.  Sounds complicated, but
from an implementation point of view ends up being simpler
that putting in elaborate referential integrity constraints.)

...
>  The new tunnels are identified by Global Id (OCTET
> STRING (SIZE 4)) or Icc Id (OCTET STRING (SIZE 6)).

%sam - which is the reason why mapping table is still
 needed whether old tunnel table or new tunnel table is used.

I'm hearing two different narratives regarding the mapping table.  :-)

...
%sam - the value of l1, though unique, having non-ip address
  value mean nothing, even to the legacy application. That is
  why, re-using the table with non-ip value is a perfect choice.

This seems to be the key point of disagreement, and is really
at the heart of whether there's a potential operational problem.
Two different people reading the MIB have come to different
understandings of the significance of "I1".  Perhaps it would
be helpful for both of you to go back to the source documents to
understand (1) how you came to your own understanding
of the situation, and (2) to look for clues that might have lead
the other person to read it another way.

Randy

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 26 Nov 2012 22:43:52 -0800

Hi Randy,

Thanks for the reply.
Find comments in line with %sam2.

Sam

Sent from my iPad

> that putting in elaborate referential integrity constraints.)
%sam2- yes, we have indeed added examples for associated and co-routed tunnels, so that there is not much confusion. Let me know if they could be improved in any way. I may not have communicated properly, what I wanted to, in my earlier comment. All I was saying is, for ex: in the case of associated tunnels, mid point device may not have reverse direction tunnel, as it could traverse via different path. 
> I'm hearing two different narratives regarding the mapping table.  :-)
%sam2- ignore my earlier comment for now. Can address later, if needed, and not is things up.
> the other person to read it another way.
%sam2- if I understand right, the point of disagreement is, in the existing MIB, the index value hold router ID, which identifies the device. This requires the value to be valid IP address. So, legacy applications, could use it to identify the device.

What the new MIB extension proposes is, to use the index with value on non-ip address I.e 0 to 1.0.0.0.0. The value within this range doesn't have global significance, even for legacy applications. So, using it as local identifier to find the actual identifiers via map table is a neat way of indirection.

Ideally, we would have liked TE MIB foresee the TP requirements and have had extensible index :D. Unfortunately it is not the case.

Sam

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 27 Nov 2012 00:02:44 -0800

Hi -

> 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: Monday, November 26, 2012 10:43 PM
...
> %sam2- if I understand right, the point of disagreement is, in the
>  existing MIB, the index value hold router ID, which identifies the device.
> This requires the value to be valid IP address. So, legacy applications,
> could use it to identify the device.
>
> What the new MIB extension proposes is, to use the index with value
> on non-ip address I.e 0 to 1.0.0.0.0. The value within this range
> doesn't have global significance, even for legacy applications.

Would it be fair to say that there is a set of values (i.e 0 to 1.0.0.0)
permitted by the syntax and description of the old index, but which,
due to the normal operation of implementations, would not be observed
in a legacy environment?

I think part of Joan's concern is whether anything in the original
specification would lead implementors to do something bad
with the handling of values from within that range, like
<waving arms>
trying to do a traceroute to that IP address
</waving arms>.

That is a legitimate concern.  For me, a more callous attitude
leads my thinking:

If the original specification did nothing to suggest that that range
would be "off limits", then I think there's no problem.  When
implementors read constraints into an OBJECT-TYPE that
aren't supported by the SYNTAX or DESCRIPTION, they
have only themselves to blame if a later usage of that
module doesn't obey the constraints they imagined.

Wise designers will recognize the truth in both positions,
and consider operational practice and deployed implementations
in weighing their decisions.  :-)

For the original data type to have been Unsigned32, rather than
an adress type, biases me towards rejecting the notion that
management applications would be justified in casting it
to an IPv4 address.  But what management applications
actually *do* will trump any of my theorizing.

> So, using it as local identifier to find the actual identifiers via map
> table is a neat way of indirection.
>
> Ideally, we would have liked TE MIB foresee the TP requirements
> and have had extensible index :D. Unfortunately it is not the case.

It still sounds like you and Joan need to figure out whether there
really *is* a map table or not.  :-)  Even if it's not part of the final
RFC, and E-R diagram might be helpful.

Randy

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 27 Nov 2012 07:54:54 -0800

Hi Randy,

Comments inline with %sam3.

-sam

> due to the normal operation of implementations, would not be observed
%sam - Correct. Here is why
"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 }

Though the non-ip value is permitted, the semantics of the object restrict it to valid router ID. 
So, the range from 0 - valid ip is implicitly not used.

> trying to do a traceroute to that IP address
%sam3- It is legitimate concern. The question is, how can one perform trace route to invalid ip address?
> actually *do* will trump any of my theorizing.
%sam3 - Three implementors of the this MIB have tested this with their own management applications. None had issue  because, when it encounters invalid-ip as the ingress or egress LSR ID, it identifies that it is not a legacy TE tunnel.
I cannot speak for every application though.
> RFC, and E-R diagram might be helpful.
%sam3 - Any info needed to clear the confusion, we definitely could add that. Hopefully, Joan is OK with this.

-sam

---

From: "Joan Cucchiara" <[email-masked]>
Date: Tue, 27 Nov 2012 14:28:59 -0500

----- Original Message ----- 
From: "Randy Presuhn" <[email-masked]>
To: "Sam Aldrin" <[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: Tuesday, November 27, 2012 3:02 AM
Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance 
ondraft-ietf-mpls-te-tp-mib-05.txt

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

Randy,

Yes, you have hit the nail on the head!

> actually *do* will trump any of my theorizing.

I am perhaps being too literal.   The original MIB says this value is used 
to "identify" the Ingress/Egress of the  LSR (Lable Switch Router).
In MPLS every router in the network is given an LSR Id (this is typically 
the 4 byte Router Id).   I think for purposes of this discussion
the LSR Id is equivalent to the Router Id.

To quote from the original MIB (rfc3812):

mplsTunnelIngressLSRId
DESCRIPTION "Identity of the ingress LSR associated with this tunnel 
instance..."

mplsTunnelEgressLSRId
DESCRIPTION "Identity of the egress LSR associated with this tunnel 
instance."

In other words, the LSR ID of the router which is unique within the LSR's 
network.

I1  contains the LSR ID.   (There are actually 2 INDEXES for each Tunnel 
Entry,  one for Ingress and one for Egress, but think using I1 is fine.)

(So yes, I am concerned about those legacy apps that use the LSR ID.)

The proposed draft is creating a value (I2) in T2, which does NOT  identify 
the LSR of the Ingress/Egress and then creates a Row in
T1 with an I1 which is equal to I2   (so now I1 is  some non-IP number which 
is NOT the LSR ID
of the Router which has the Ingress/Egress).

As far as I can tell (and Sam could confirm this?) Tunnels with TP have an 
LSR ID also BUT this LSR ID has 2 possible types:
(Global_Node_ID which is an OCTET STRING (SIZE 4)) and is related to an ASN, 
or ICC which is an OCTET STRING(SIZE 1..6))

 So this is the question:  If the DESCRIPTION specifies
that an INDEX has the value of an Identifier (like Router Id, or LSR ID) 
and the SYNTAX allows for values which are not the Identifier (the non-IP 
range), can a subsequent MIB come along which defines values (non-IP range) 
that are not an Identifier, even if the DESCRIPTION says that it is an 
Identifier?

The only way to get the LSR ID for Tunnels with TP is to use the I2 (which 
== I1) (i.e. the non-IP range)  to do a look-up of an Identifier (i.e. one 
of the new types of LSR ID for Tunnels with TP (Global_Node_ID or ICC_ID)? 
(I have been calling this map, so map or associate I2 with a value that is a 
new type of LSR ID.)

So, yes, I am definitely concerned about the legacy apps that could be 
broken, but am also concerned because the DESCRIPTION says that it is
an Identifier of a Router, and the proposed draft is assigning a value that 
is not an Identifier of a Router.

> RFC, and E-R diagram might be helpful.

I agree.

-Joan

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 27 Nov 2012 14:05:01 -0800

Comments inline.

On Nov 27, 2012, at 11:28 AM, "Joan Cucchiara" <[email-masked]> wrote:

> Cc: "Joan Cucchiara" <[email-masked]>; "Venkatesan Mahalingam" <[email-masked]>; "MIB Doctors (E-mail)" <[email-masked]>; "venkatesan mahalingam" <[email-masked]>; "Kannan Sampath" <[email-masked]>
%sam - I do not think that is an issue. Two reasons
1. In IPv6 network, router ID is explicitly configured as IPv4 address (for OSPF). Traceroute will fail in legacy applications as well.
2. In the LSR ID is non-ip address, one cannot(should not) perform trace route.
> I am perhaps being too literal.   The original MIB says this value is used to "identify" the Ingress/Egress of the  LSR (Lable Switch Router).
> In MPLS every router in the network is given an LSR Id (this is typically the 4 byte Router Id).   I think for purposes of this discussion
> DESCRIPTION "Identity of the ingress LSR associated with this tunnel instance..."
> 
> mplsTunnelEgressLSRId
> DESCRIPTION "Identity of the egress LSR associated with this tunnel instance."
> 
> In other words, the LSR ID of the router which is unique within the LSR's network.
> 
> I1  contains the LSR ID.   (There are actually 2 INDEXES for each Tunnel Entry,  one for Ingress and one for Egress, but think using I1 is fine.)
> 
%sam - May be it would be helpful if you could list out potential issues for legacy applications, when non-ip address value is used for the LSR ID.
> 
> The proposed draft is creating a value (I2) in T2, which does NOT  identify the LSR of the Ingress/Egress and then creates a Row in
> T1 with an I1 which is equal to I2   (so now I1 is  some non-IP number which is NOT the LSR ID
> As far as I can tell (and Sam could confirm this?) Tunnels with TP have an LSR ID also BUT this LSR ID has 2 possible types:
> (Global_Node_ID which is an OCTET STRING (SIZE 4)) and is related to an ASN, or ICC which is an OCTET STRING(SIZE 1..6))
%sam - Partially correct. For ICC type, it is Octet string as mentioned. For IP type, it is made up of (GlobalID+NodeID) +Tunnel Num will identify the device.
> that an INDEX has the value of an Identifier (like Router Id, or LSR ID) and the SYNTAX allows for values which are not the Identifier (the non-IP range), can a subsequent MIB come along which defines values (non-IP range) that are not an Identifier, even if the DESCRIPTION says that it is an Identifier?
%sam - If I understand Randy'e email, it is OK to define value to use non-ip range.
> 
> The only way to get the LSR ID for Tunnels with TP is to use the I2 (which == I1) (i.e. the non-IP range)  to do a look-up of an Identifier (i.e. one of the new types of LSR ID for Tunnels with TP (Global_Node_ID or ICC_ID)? (I have been calling this map, so map or associate I2 with a value that is a new type of LSR ID.)
> 
> So, yes, I am definitely concerned about the legacy apps that could be broken, but am also concerned because the DESCRIPTION says that it is
> an Identifier of a Router, and the proposed draft is assigning a value that is not an Identifier of a Router.
%sam - It is an identifier of a router, which has local significance. The name of the object, in the NodeConfigTable  also emphasize that. Using the mplsTunnelExtNodeConfigTable, described in sec 8.0, one could map the TP identifies to a local identifier, which could be used index into Tunnel table. 
In order to resolve, may be it is good to table the issues of legacy applications and discuss about them. Three of the applications I know off, didn't have the issue dealing with the non-ip value for Tunnel indices.

cheers
-sam

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 27 Nov 2012 17:18:28 -0800

Hi -

> Sent: Tuesday, November 27, 2012 11:28 AM
...
> to "identify" the Ingress/Egress of the  LSR (Lable Switch Router).

FWIW, I only understood that to be in the context of the table,
rather than as being an externally usable name.  The bits of
"SHOULD" language cited in this thread (rightly or wrongly)
reinforced that impression, since to me a "SHOULD" means
"one must not rely on this provision".

> the LSR Id is equivalent to the Router Id.

Here's where we perhaps differ in our thinking.  If it "is typically" rather
than "MUST be", then code that uses the value outside the scope of
the table is employing a fallible heuristic.

> DESCRIPTION "Identity of the ingress LSR associated with this tunnel

For me the rest of the DESCRIPTION is critical in determine the extent
to which this value might be usable:
             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.

I read this as saying that for rsvp(2) and crldp(3) there are heurstics
(but NOT guarantees) of what the index value *might* equal, and that
for any other signalling protocols, all bets are off.  The language says
it *might* be equal to Tunnel Sender Address, or it *might* be equal
to Extended Tunnel Id, or it *might* be LSR Router ID, or it might be
equal to none of these.

> In other words, the LSR ID of the router which is unique within the LSR's

This one clearly lacks the wiggle room of the other, though the scope of
"identity" (unique within this table in this instance of this implementation,
or unique within this network?)

> of the Router which has the Ingress/Egress).

That depends on how one understandards "identify".  If it's merely in a
MIB sense (as in INDEX), there's no problem.  If it's in the sense of
"uniquely name something in the network in a way that non-SNMP
infrastructure might use", then there's probably a problem.

> that are not an Identifier, even if the DESCRIPTION says that it is an

That leads me to look at:

       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)

Now perhaps I'm reading too much into this, but to me the use of
"may", the decision to use the Unsigned32 data type rather than
an address data type, and the talk about the value being "derived"
all suggest that any reliance on the value actually being equal to a
usable IP address would be unwarranted.

> is not an Identifier of a Router.

Bringing us back to the question of whether they intend "identifier" to be
of network-wide usability or merely for navigating within the MIB's tables
accessed through a particular agent.

Randy

---

From: "Joan Cucchiara" <[email-masked]>
Date: Wed, 28 Nov 2012 09:38:51 -0500

----- Original Message ----- 
From: "Randy Presuhn" <[email-masked]>
To: "Joan Cucchiara" <[email-masked]>; "Sam Aldrin" 
<[email-masked]>
Sent: Tuesday, November 27, 2012 8:18 PM

> to Extended Tunnel Id, or it *might* be LSR Router ID, or it might be

Yes, I can see that.

Randy,

I think you have some valid points in your analysis of the DESCRIPTION 
clauses, so Thank you for that.   I would think (as you pointed out above) 
that the use of the word, "may" would indicate that the identifier is for 
navigating within the MIB's tables, and similar reasoning would be applied 
if legacy apps break due to the additional 2 new types added by the proposed 
draft.

I think there are far better ways to represent a design which is like a C 
language switch statement.   Adding another "case" which is actually one of 
two possibilities  in hindsight in a different MIB doc, is perhaps unwise, 
but as you points out,  it doesn't seem to break the SMI.

Thanks again for your insight,
-Joan

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 28 Nov 2012 13:00:42 -0800

Hi -

> Sent: Wednesday, November 28, 2012 6:38 AM
...
...

I think the thing most clear from this discussion is that the RFCs could have been
much clearer about what was intended.  In particular, I think this is a cautionary
tale about the putting optional algorithms for the derivation of index values into
description clauses without making the consequences of the optionality clear.

The C construct all this reminds me of is the type cast, rather than the switch,
since bit patterns are shoveled around in ways that result in the loss of their
semantics, but tempt code maintainers to try to re-assert those semantics.

Randy

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 28 Nov 2012 14:07:34 -0800

Hi Randy and Joan,

Really appreciate all your comments and concerns.
Will re-spin a new version and put in more details, which should give clear picture on what the model and incorporate necessary text to remove any ambiguity.
I will update the tracking excel sheet to incorporate all the received comments.
Feel free to send in any suggestions or comments. Will be happy to address them and make any changes necessary.

cheers
-sam