Subject: RE: owner object in LSR MIB

From: Cheenu Srinivasan <[email-masked]>
Date: Wed, 10 May 2000 09:07:35 -0400

Hans,

Let me summarize the response Tom is referring to which we sent to
you yesterday. I agree that this is something the group at large needs
to consider.

We believe that the purpose your were trying to achieve in the context of
the discussion about the owner object is the following:
When a LDP session is torn down, you want to identify and remove the
associated cross-connections.

In order to do that what is required is a table that given the
session identifier enables us to locate all the associated LSPs. Having a
back pointer to the session in the LSR MIB doesn't not achieve
your purpose, because given a session id you would have to walk the
entire cross-connect table to identify all the LSPs associated
with that session.

It seems that the only solution to the above problem is to create
a separate table in the LDP MIB indexed by the session identifier
which will return a list of cross-connects associated with that session.

One way to achieve this is to make a row pointer to a cross-connect
entry the secondary index of such a table.

Given this understanding, the discussion about the owner object or
a new object in the LSR MIB is moot. As you can see, this is not
an issue that comes about because you are trying to align the LDP
MIB with the LSR MIB, rather this is an issue inherent in the LDP
MIB that needs to be addressed there.

Thanks,
Cheenu

---

From: Hans Sjöstrand <[email-masked]>
Date: Wed, 10 May 2000 17:50:51 +0200

> associated cross-connections.

If a session is torn down, the LSPs will have to be released. This 
is part of the protocool and it's impossible to rely on the management 
system to do the cleaning. so this isn't the use and I never stated
that. 

> entry the secondary index of such a table.

I agree that thi sis the best solution to the specific problem, but
I don't regard this as the application.  

> MIB that needs to be addressed there.

When we did the modelling we regarded this as a requirement and modelled 
it in. Poosible applications are e.g
- Network Management operation to clean up hanging resourses. This could 
be a way to find LSP segments that due to network errors are hanging.
Not
an everyday job but useful anyway. 
- In my opinion the session pointer is one of the properties of an LSP
and therefore one of an LSPs objects. This could be for simple
management 
or troubleshooting or whatever management task. I don't want to think
out
all future users, just provide the tools for efective managemetn. Thats
what mib design is about. 

The simple fact that it was in when it was in the LDP MIB and it's out
and 
proposed to be in the LSR MIB makes it in my mind an alignemnet issue. 

regards
/// Hasse