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

[Rajiv Raghunarayan <rrajiv@cisco.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. 

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/