Re: Non-member submission from [Roland.Meyer@nokia.com]

[Jon Saperia <saperia@jdscons.com>]

> Hi Jon,
> 
> Jon Saperia wrote:
> > 
> > Thanks for the clarifications. The only observation I would make is that
> > you can not use the index inetCidrRouteInstance for two different
> > things. Either it is for vpn use or a typical integer index value which
> > would reasonably increase one at a time as indices are added to the
> > table. I assume you did not mean to imply otherwise, or have I missed
> > something?
> 
> Yes. I did mean that we could use it to represent various types
> of info, but only one at a time i.e. either it represents Tos or
> it represents VPN id, but not both. 

I do not see how you would do this without adding at least one more
object to your index since the semantic meaning of the object would
differ. It could be done, it just requires more than is there now.

> 
> Don't think it could represent more than one at a time, unless we 
> have another unique way to identify what its representing eg. values 
> below X represent TOS and above X represent VPN id, or maybe another
> object representing type of info.
> 
> -Rajiv.
> 
> > 
> > Thanks
> > /jon
> > > Hi Jon,
> > >
> > > Jon Saperia wrote:
> > > >
> > > > Thanks very much. I looked at the Inet CIDR Route Table since if it were
> > > > every widely implemented correctly, it would be very helpful.  I think
> > > > it is just what I was looking for. I assume the following are true
> > > > statements:
> > > >
> > > >         1. When done this table will replace the current CIDR Route
> > > >         Table since it is designed to hold both v4 and v6 addresses.
> > >
> > > Yes. The new CIDR Route table i.e. inetCidrRouteTable, is a superset
> > > of the ipCidrRouteTable, and would (in all probability) deprecate
> > > the existing table.
> > >
> > > >
> > > >         2. The general index structure is pretty helpful and can be used
> > > >         as a model for tables in the future that need network layer
> > > >         addresses as their indicies.
> > >
> > > The index structure has been more or less maintained from RFC 2096
> > > (except for ipCidrRouteTos being replaced inetCidrRouteInstance).
> > > inetCidrRouteInstance seems to have been designed with universal
> > > applicability in mind i.e. it could also represent Tos based
> > > classification but could also be used cases of multiple routing
> > > tables - say for VPN.
> > >
> > > Note that the MIB also makes a comment that this object needs to
> > > discussion (maybe a more detailed specification of what can/cannot
> > > be represented by it). So, I guess, we need to wait and see what
> > > its finally defined as..
> > >
> > > -Rajiv.
> > >
> > > >
> > > > /jon
> > > >
> > > > > Hi Roland,
> > > > >
> > > > > "Wijnen, Bert (Bert)" wrote:
> > > > > >
> > > > > > Forwarding a non-meber posting
> > > > > >
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Perhaps somebody can answer the following questions:
> > > > > > >
> > > > > > > What is the current state of the IPv6MIB design?
> > > > >
> > > > > All I can say here is that these MIBs are being modelled on the
> > > > > lines of the existing IPv4 MIBs. Not sure about how much work
> > > > > is still to be done, guess that part could be better responded
> > > > > to by the authors..
> > > > >
> > > > > > > Where can one find (preliminary) results of the design work?
> > > > >
> > > > > You can find the draft versions of these MIBs at
> > > > > http://www.aciri.org/fenner/mibs/v6/
> > > > >
> > > > > HTH.
> > > > >
> > > > > Rajiv.
> > > > >
> > > > >
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Roland
> > > > > > >
> > > > >
> > > >
> > > > Thanks,
> > > > /jon
> > > > --
> > > >
> > > > Jon Saperia                  saperia@jdscons.com
> > > >                              Phone: 617-744-1079
> > > >                              Fax:   617-249-0874
> > > >                              http://www.jdscons.com/
> > >
> > 
> > Thanks,
> > /jon
> > --
> > 
> > Jon Saperia                  saperia@jdscons.com
> >                              Phone: 617-744-1079
> >                              Fax:   617-249-0874
> >                              http://www.jdscons.com/
> 

Thanks,
/jon
--

Jon Saperia		     saperia@jdscons.com
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/