Subject: RE: prequeal to WG lat call om the LSR mib module

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 10 Jun 2003 15:59:21 -0400

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Tuesday, June 10, 2003 3:46 PM
> To: [email-masked]; 'MPLS WG'
> Subject: RE: prequeal to WG lat call om the LSR mib module
> 
> 
> So if you have 3 application managing Label Space as
> in the following example. 
> > 
> > 	Application		Incoming Labels Owned by Application
> > 	LDP			{ 15, 29, 45 }
> > 	VPN			{ 30, 31, 32 }
> > 	TE  			{ 16, 17, 18 }
> > 	
> And then you have the object mplsInSegmentIndexNext
> 
> How does that IndexNext object provide me with a proper
> new index value that I can use. Cause it does not know 
> if I (as an application) want to create a new InSegment 
> for LPD, VPN or TE... or does it? If it does, then I
> do not understand how. Maybe I missed the explanation in
> some text in the MIB document... if so, pls point me to it.

	It knows because it knows which device it is
provisioning and thus knows what the application ID
values need to be (from its agent cap statement or
other documentation). I don't see this as a problem since
there is a whole slew of non-standard things that a
provisioning system needs to know about devices it
manages. In fact, I would bet that %100 of the implementations
out there will require some bit of proprietary MIB support
to facilitate provisioning of static LSPs via SNMP (if
they even will allow this). IMHO the fact that we have %90 
of what most people need is not too bad.

	--Tom

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 10 Jun 2003 21:46:10 +0200

Bert

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 10 Jun 2003 16:29:57 -0400

Tom,

This comes close to my question a little while back.
The issue is not "How does the management application know what it is
provisioning?", but "How does the device know what is being provisioned?"

If you are saying - it knows it through some proprietary MIB field that people
will add to the their own MIBs - this is fine, but I say let's add an explicit
applicationIndex field that implementations can interpret freely.

If you are saying - the application index is embedded in the inSegementIndex - I
say this doesn't work because there is no way of communicating the requirements
to the getNext object on a GET command.

Adrian

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 10 Jun 2003 16:56:24 -0400

> The issue is not "How does the management application know 
> what it is provisioning?", but "How does the device know what 
> is being provisioned?"

	Simple, it knows the format of the index based on
local information.  This IMHO is no better than having
an explicit application ID because the NMS still needs to
know how that is encoded. The benefit of just having
an opaque value again is that it is a LOCAL decision as
to how to encode the application ID. If I only have 2 applications,
I can just use 1 bit instead of 32, for instance, and
reduce the over-all length of the indexes.
 
> If you are saying - it knows it through some proprietary MIB 
> field that people will add to the their own MIBs - this is 
> fine, but I say let's add an explicit applicationIndex field 
> that implementations can interpret freely.

	Yes, this is what I was thinking sans the extra index. 
Implementations can have a proprietary "I want the next index from 
his application" variable to SET and lock so that the next read from 
the index next variable gets you the next one from the desired 
application's "bag" of labels. However, I don't think that having 
an applicationIdNext and an explicit application ID object in the LSR 
MIB is going to solve this problem or even help it much more than 
just using an octet string that an implementation can reveal the
internal formatting of in its documentation. In fact I think that it 
is just going to complicate things in the LSR MIB and other
MIBs like LDP that use the indexes from the LSR MIB.

	--Tom

> If you are saying - the application index is embedded in the 
> inSegementIndex - I say this doesn't work because there is no 
> way of communicating the requirements to the getNext object 
> on a GET command.

> some text 
> > > in the MIB document... if so, pls point me to it.
> >
> there is a 
> > whole slew of non-standard things that a provisioning 
> system needs to 
> > know about devices it manages. In fact, I would bet that 
> %100 of the 
> > implementations out there will require some bit of proprietary MIB 
> > support to facilitate provisioning of static LSPs via SNMP (if