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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 11 Jun 2003 00:15:36 +0200

So Adrian understands the problem the same way I do it.
And your solution that this NEEDS some proprietary
MIB object or other mechanism to FIRST tell the agent
that my next GET for the mplsInSegmentIndexNext is
gonna be for a VPN segment is NOT ACCEPTABLE, at least
not to me. I would be really surprised if other WG
members buy such a (non-)solution.

Thanks,
Bert 

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: dinsdag 10 juni 2003 22:56
> To: 'Adrian Farrel'; 'Wijnen, Bert (Bert)'; 'MPLS WG'
> Subject: RE: prequeal to WG lat call om the LSR mib module
> 
> 
> 
> 
> > 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?"
> 
> 	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.
> 
> 
> 	
> 
> > Adrian
> > 
> > ----- Original Message -----
> > From: "Thomas D. Nadeau" <[email-masked]>
> > To: "'Wijnen, Bert (Bert)'" <[email-masked]>; "'MPLS WG'" 
> > <[email-masked]>
> > Sent: Tuesday, June 10, 2003 3:59 PM
> > Subject: RE: prequeal to WG lat call om the LSR mib module
> > 
> > 
> > >
> > >
> > > > -----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: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 11 Jun 2003 10:01:36 -0400

Bert,

	Unless we standardize the formatting of
the application ID index, you still have
the same problem with Adrian's approach. In essence,
you still need to know a) how the app IDs 
are assigned, and b) you need to tell the agent
which app ID you want to get an index from
BEFORE you do the row creation. 

	Since we are spinning around in the mud
on this, let me make a proposal that would
make this problem go away. Lets make
the LSR MIB entirely read-only. This way we 
can give it fast indexing for retrieval based
on a single opaque octet string which 
not only gets you O(1) individual searches,
but also O(1) MIB walks, and then
let application-specific MIBs be created
that are specific to the applications
being provisioned, and provide the correct
indexing for each application to do that
provisioning there. We could then provide
a mapping from there to the index used in
the LSR MIB so that once a new label was
provisioned, it can be associated with the
opaque index used in the LSR MIB. We did this 
in the PWE3 WG for those MIBs, and it seems 
to make a lot of sense.

	In summary, let me give a quick example:

LSR-MIB's inSegmentTable is indexed by the
single octet string. If I want to provision a static 
label for a static LSP, I go to the MPLS-Static-Label-Prov 
MIB and create an entry based on ifIndex of 5,
and IP destination prefix of 1.2.3.4. That entry 
once created, will be indexed by those items.
It will also have an object (not an index)
called MplsLsrInSegmentIndex that is
populated by the agent, say to 0x050501020304
which can be used to cross-reference entries
in the LSR MIB's mplsInSegmentTable.

	--Tom

> > 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.
> >  
> > > > > 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
> values need to 
> > > > be (from its agent cap statement or other 
> documentation). I don't 
> > > > see this as a problem since
> > > there is a
> > > > they even will allow this). IMHO the fact that we have 
> %90 of what 
> > > > most people need is not too bad.
> > > >
> > > > --Tom
> > > >
> > > >
> > > 
> > > 
> > > 
> > 
> > 
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 11 Jun 2003 10:44:57 -0400

Tom wrote...

> the LSR MIB entirely read-only.

Yeah, right.
Let's remove half the utrility of this MIB!

There is valuable utility to write-access in the LSR MIB. Manually provisioned
LSPs (PVC-style) are important in all networks, but especially in ATM and FR. If
you talk to your transport people, they'll tell you that support for this
function in the GMPLS/TDM/optical world is essential.

This is a non-starter. We discussed the need for this MIB to have write access
at least three years ago, and added it then.

Adrian

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 11 Jun 2003 10:59:14 -0400

> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Wednesday, June 11, 2003 10:45 AM
> To: [email-masked]; 'Wijnen, Bert (Bert)'; 'MPLS WG'
> Subject: Re: prequeal to WG lat call om the LSR mib module
> 
> 
> Tom wrote...
> 

	I disagree that half of its utility is
in read-write access. Is anyone really using it
for provisioning anyway? In the nearly 4 years that
I have been working on this MIB I have been made
aware of precisely 0 implementations that used it
in a writable mode.  If you have been, please stand
up and be heard!
 
> There is valuable utility to write-access in the LSR MIB. 
> Manually provisioned LSPs (PVC-style) are important in all 
> networks, but especially in ATM and FR. If you talk to your 
> transport people, they'll tell you that support for this 
> This is a non-starter. We discussed the need for this MIB to 
> have write access at least three years ago, and added it then.

	I am not disputing that provisioning functions are 
essential, but they are not possible in the LSR MIB
without lots of other changes. Your proposal will not
fix the provisioning issue you raised. Why don't we just 
punt on provisioning and re-visit the issue with a 
provisioning-specific MIB in the future that allows for 
specific per-application provisioning semantics?  
This is indeed at the heart of the issue you raise.
This is perfectly acceptable too. The AD stated at
a recent IETF meeting that it was indeed okay for 
WGs to produce read-only MIBs if there was consensus 
to do so.

	--Tom