RE: GMPLS MIB I-D updates

[Kireeti Kompella <kireeti@juniper.net>]

On Sat, 26 Jan 2002, Wijnen, Bert (Bert) wrote:

> >          I don't see the new MIBs as obsoleting the v1 MIBs.
> > The existing MPLS MIBs will continue to be perfectly
> > valid for existing implementations, as well as future ones that do not
> > want to have anything to do with GMPLS.

Speaking as an implementor, I would prefer that these MIBs *do*
obsolete the v1 MIBs.  That doesn't mean that the v1 MIBs should
be thrown away, just that (perhaps) they could be experimental instead
of PS (repeat: the above comment is *not* as a WG chair).

> >          The new v2 MIBs need to support the new GMPLS functions
> > as well as existing MPLS functions (since GMPLS is based on MPLS),
> > and I think there is sufficient reason for to stand on their own
> > while leaving the first versions of these MIBs as RFCs.
> > 
> OK, that sounds plausible.

> BUT......
> 
> Then I think you should try and duplicate as few objects from the old
> MPLS MIBs as possible. So only new stuff that is needed should be in
> the GMPLS MIBs. If Someone needs both MPLS and GMPLS MIB funcrtionality,
> they then implement both the MPLS MIBs and the GMPLS MIBs.
> 
> I think that that means that you should not consider them as version2 
> of the MPLS MIBs, but as MIBs that provide GMPLS function only.

I agree.  If the v2 MIBs provide minimum overlap, then they are
not really v2, and there is no need to obsolete the v1 MIBs (in fact,
one couldn't do that).  If the v2 MIBs are (for whatever SNMP-technical
reason) full, stand-on-their-own MIBs, then let's consider making the
v1 MIBs experimental or whatever.

I leave the naming of the MIBs to the SNMP experts.  The WG, however,
should be CCAMP.

Kireeti.