Subject: owner object in LSR MIB

From: Hans Sjöstrand <[email-masked]>
Date: Tue, 09 May 2000 17:37:12 +0200

This has been discussed to some degree off line previously but is now
part of the LSR last call comments so I post it on the list. LSR MIB
authers, sorry to reiterate a little. 

The LDP mib has been updated to use the LIB tables in the LSR MIB to
meet the last call comments. In order to fully align the LDP and LSR
MIBs in a good way we would like you to consider the following proposal. 

To transform the owner object in the inSegment/outSegment/XC tables
into something more loosly defined e.g just a OCTET STRING. THe object 
description could be something like (just off my head, it should be
frased better)

   DESCRIPTION
       "Denotes the name of the entity that created and is responsible
        for managing this segment. This object could be provisioned 
        by the manager or it could be generated by the agent."

This will take care of some shortcomings of the LSR LIB and also 
address some last call concerns on the objects. 

- It gives LDP the chance to tie the session to the LSP. 
I.e in the LDP MIB we will qualify the use of the owner attribute to 
identify the session responsible for managing it. 
- It takes away the slightly bad practice to have an enumerated value 
which qickly is outdated, e.g GSMP which are being defined for the 
purpuse of establishing LSPs. 
- Other advantages could be build in the change. 

This requires minimal change in the LSR MIB (only a small syntactic
change,  no new object or anything. This takes care of one of our 
main obstacles in just using the LSR MIB LIB, being what session 
to tie an LSPs to. This is important for a number of reasonsto LDP. 

Regards
/// Hasse

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 09 May 2000 12:05:30 -0400

Hans,

         Can you please ready our comments from
yesterday and see if they resolve your problems?
The thread you are posting here is post our
reply from yesterday.

         --Tom

---

From: Hans Sjöstrand <[email-masked]>
Date: Wed, 10 May 2000 14:36:43 +0200

> Subject: LSR MIB Comments From Earlier
> Date: Thu, 04 May 2000 17:19:37 -0400
> From:"Thomas D. Nadeau" <[email-masked]>
> To:"Cucchiara, Joan" <[email-masked]>,
>    Hans Sjöstrand <[email-masked]>
>
>         Hi,
> 
>         Could you guys please re-state your
> questions for the larger mailing list? Now
> that we have a second last call, those
> comments should be voiced on the public forum
> to make sure that others can be aware of them
> and that they are on record in the archives.
> 
>         --Tom

Thats what I did, and I think that other people should be given the
oppertunity to see the response and voice their opinion about this. 
Thats the whole idea with a last call isn't it. 

Here is a previous response from Tom on the issue, comments inline
>         Hi,
> 
> > To repeat, LDP LSPs needs to be mapped to the session that manages them.
> > I don't see how these object do that. But my proposal about using
> > the owner object for this fixes this. 
> 
> 
>         Let me reiterate how we have addressed this too. We feel
> that it will suffice for the LDP Session to point to the LSP
> via the XCIndex. The LDP Session should then delete the LDP
> *before* deleting the session.  We think that this will solve
> your problem. If you look at it this way, then the issue
> with the sessionOwner string (see below) is really orthogonal.

In the process of aligning the two mibs we agreed to take out our
LDP adjusted LIB and refer to the one in LSR MIB even though it's 
less suitable for LDP. One requirement we had on that LIB was to
be able to tell what session an LSP belonged to. We asked you to 
add this feature to the LSR MIB in a flexible and 
protocool-independant way. You seam to think that this is useless
requiremnt and don't want to add the feature. Two different opinions!

What does the list think, is it a viable requirement to have information 
about what LDP session created the LSP stored with the LSP? 

I see applications such as accounting, troubleshooting and simple
management. 

> 
>   > Could I propose to transform this into something useful by having a 
>   > loosly defined owner type, e.g just a OCTET STRING. The object 
>   > description could be something like (just off my head)
> 
> 
>         The problem with making this value a free-form octet
> string is that its definition is not standard, and hence
> may not be inter-operable.

An object is not defined solely by it's type, it also have it's 
DESCRIPTION clause which could contain information. My proposal 
was to open the object, make it protocool independant so it 
could be qualified in other protocool specific MIBs. I was clear
that the proposed DESCRIPTION should be improved. I could happily 
work togehter with you to get that right one it's agreed that is 
the path to take. 

Regards
/// Hasse

> Hans Sjöstrand wrote: