RE: GMPLS MIB I-D updates

["Thomas D. Nadeau" <tnadeau@cisco.com>]

At 12:51 AM 1/26/2002 +0100, Wijnen, Bert (Bert) wrote:
> > > > 2. We believe CCAMP is the appropriate place to continue this
> > > >    work since the extensions are completely GMPLS related. This was
> > > >    discussed in Salt Lake City and (we thought) agreed upon but
> > > >    we would like to hear the chairs'/AD's word on this.
> > > >
> > >If the MIBs are GMPLS specific, in which case they would
> > >probably conatin a set of AUGMENTing tables to the MPLS MIBs,
> > >then they may belong in CCAMP. If they are changing (i.e.
> > >just repeating and adding new objects) the base tables in the
> > >MPLS MIBs, then it seems to me that they may also belong in the
> > >MPLS WG. I'd like to hear from author how they want to approach
> > >adding GMPLS management objects to the MPLS MIBs. Then I want
> > >to hear from WG chairs how they are reading consensus on what
> > >to do and where to do it.
> >
> >          The AUGMENTS approach was originally thought though
> > (I think that we sent you email on this, but maybe not). The
> > conclusion was to not AUGMENT the existing MIBs because the
> > indexing of many of the existing tables used the MPLS label. Since
> > GMPLS allows for labels of much greater length, we could not
> > use this approach, and thus decided to write new tables that
> > were as close as the old ones as possible so as to preserve existing
> > implementations, but to also facilitate GMPLS functions (existing and
> > future).
> >
>So that to means you will obsolete the MPLS MIBs at that time.
>And tat means you recycle at Proposed Standard.
>So maybe you are to quick trying to get the current set of MPLS
>MIBs approved as PS?

         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. These MIBs have been around
for over 3 years now, and are fully cooked for "classic" MPLS. There
are many implementations that support them. Disregarding them now so
that we can wait for GMPLS-related functions will delay them for several
more years. The vendors and operators that I work and interact with
want the existing MPLS MIBs to become RFCs ASAP.

         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.

         --tom




------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.