Subject: use of MPLS OID branch

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 6 Dec 2002 22:52:28 +0100

What I was worried about when the WG does its own administration
and/or assigments of OIDs has happened.

For example:

 mplsFTNMIB MODULE-IDENTITY
     ...
     ::= { mplsMIB 5 }

 mplsLdpFrameRelayMIB MODULE-IDENTITY
     ...
     ::= { mplsMIB 5 } -- to be assigned

This is not good... Pls check them all and correct.
And what are we going to do to make sure we do not assign 
an overlap in the future and running the risk that it gets
published as RFC ??

Thanks,
Bert

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 06 Dec 2002 16:59:48 -0500

>      ::= { mplsMIB 5 } -- to be assigned

         Propose we use:

         mplsMIB.1 - MPLS-TC
         mplsMIB.2 - MPLS-LSR
         mplsMIB.3 - MPLS-TE
         mplsMIB.4 - MPLS-FTN
         mplsMIB.5 - MPLS-LDP
         mplsMIB.6 - MPLS-LDP-GENERIC
         mplsMIB.6 - MPLS-LDP-ATM
         mplsMIB.7 - MPLS-LDP-FRAME-RELAY

>an overlap in the future and running the risk that it gets

         I thought that IANA would manage the mplsMIB space,
no?

         --Tom

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 6 Dec 2002 23:20:36 +0100

>          mplsMIB.7 - MPLS-LDP-FRAME-RELAY
Seems fine

>          I thought that IANA would manage the mplsMIB space,
Well, if that is what you want (and that is fine with me) then
you need to do 2 things:

- In the MPLS-TC-MIB document you must add an IANA Considerations
  section in which you explain the new OID tree for mplsMib
  and in whcih you explain the rules/guidelines for IANA on
  how to decide on new assignments. It is a new namespace
  for IANA to maintain

- In all the MIB Modules you have, use

    ::= { mplsMib xx } -- xx to be assigned by IANA

  and add an IANA Considerations Section where you ask IANA to
  assign the value. You can suggest to assign the value as per
  your list above.

Now that we are on that topic, the things that MPLS-LDP-MIB document
imports OID branches in the GENERIC, ATM and FRAME_RELAY MIB Modules
from the LLLLDP-MIB module and then starts assigning underneath them,
that worries me in a similar manner. The assigments all happen in
different MIB mdoules (which can later move into separate documents
if they do not progress on stds track at same speed), and then
things may get out of sync.

Bert

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 06 Dec 2002 17:26:48 -0500

>   assign the value. You can suggest to assign the value as per

         Cool.

>things may get out of sync.

         I will let Joan respond to this.

         --Tom

---

From: [email-masked]
Date: Fri, 06 Dec 2002 18:33:49 -0500

>          I will let Joan respond to this.

The Generic, ATM and FrameRelay MIB modules
IMPORT from the MPLS-TC-MIB for the mplsMIB 
number (and IMPORT from the MPLS-LDP-MIB for
some objects), so would agree that the 
LDP-MIB document
needs to have IANA Consideration Section
which asks IANA for mplsMIB number 
assignments.

IF these MIB Modules move to different
documents (as Bert suggests above could
happen) then would think that these new
docs would need an IANA Considerations
Section also, right?

Would this be a reasonable solution?

  Thanks,
    -Joan

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 7 Dec 2002 00:49:34 +0100

> LDP-MIB document needs to have IANA Consideration Section
> which asks IANA for mplsMIB number assignments.
> 
Good.

> docs would need an IANA Considerations
Yeah.... but if that is what you want to do you might as well
start right away... I am not sure, I jave seen RMON WG maintain
their stuff pretty well and they do their own assignments too.
I think I only caught them once where they had an overlap.

But in case of LDP, you start to import from various branches
in the OID tree... and so maintaining a list of which subtrees
have been used and which are still avialable gets more difficult

For exmample

- mpls-ldp-atm-mib imports:
       mplsLdpEntityObjects,
       mplsLdpSessionObjects,
        ...
           FROM MPLS-LDP-MIB

And then assigns branches underneath those:
   mplsLdpEntityAtmObjects  OBJECT IDENTIFIER ::=
                                 { mplsLdpEntityObjects 6 }

And that is still kind of easy to locate. But then you have:

   mplsLdpAtmSesTable OBJECT-TYPE
       ...
       ::= { mplsLdpSessionObjects 10 }

So it does not look very consistent does it?

And then GENERIC and FRAME-RELAY mib modules do similar things I think.
How do you keep track?

Bert

---

From: [email-masked]
Date: Sat, 07 Dec 2002 09:23:07 -0500

>And then GENERIC and FRAME-RELAY mib modules do similar things I think.

I see your point.  Think we can probably do away with some (most?) of this
sort of dependency by not importing the subOids, but need to think
about this some more -- will make a note to address this issue in
the next (9a) version.

  Thanks, 
    -Joan

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 11 Dec 2002 16:22:41 -0500

>docs would need an IANA Considerations

         Yes, I think we would if we want IANA
to maintain the OIDs under MplsMIB. If we
do not, then only the TC needs the IANA
considerations document, and the others
probably need some paragraph (common among
all other docs) that explains where the MplsMIB OIDs
come from (i.e.: you must ask the WG).

         --Tom

>Would this be a reasonable solution?

"The difficult, we do immediately.  The impossible takes a little longer." 
-- Air Force Motto

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 12 Dec 2002 01:22:08 +0100

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: woensdag 11 december 2002 22:23
> To: [email-masked]
> Cc: Wijnen, Bert (Bert); Mpls (E-mail); [email-masked]
> Subject: RE: use of MPLS OID branch
> 
> >On Fri, 06 Dec 2002 17:26:48 -0500 "Thomas D. Nadeau" 
> <[email-masked]> >wrote:
> >

.. snip ..
> come from (i.e.: you must ask the WG).
Well... you are assuming the WG will exist forever here, are
you not? And I don;t think that that is a given.

Bert

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 11 Dec 2002 19:33:36 -0500

>you not? And I don;t think that that is a given.

         I had thought of that, but then I though why
would MIBs for MPLS be developed that go under
the MPLS branch w/o concent of the MPLS WG (or
one responsible for maintaining the OID tree)?  I guess
the question is how did the WG you cited earlier
keep track of them? If you think there will be any problems,
I vote we just give the OID maintenance to IANA.

         --Tom

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 12 Dec 2002 01:43:33 +0100

> I vote we just give the OID maintenance to IANA.
That WG is the RMON WG. 
And I am worried baout them too. They are still around for a
while. but they will shutdown at some point. I think at that
time I also do want them to write an IANA considerations
that explains how new assignments will be done.

Bert

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 12 Dec 2002 11:02:18 -0500

>that explains how new assignments will be done.

         I cannot speak for Joan and the other co-authors, but
given your description, I personally don't want to have to
be involved in policing the OID space, so I vote that we
just go with an IANA management of the MplsMIB OID
space.

         --Tom