Subject: Re: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt

From: Daniel Joyal <[email-masked]>
Date: Wed, 30 Apr 2003 15:00:34 -0400

> -----Original Message-----
> From: Acee Lindem [mailto:[email-masked]]
> Sent: Wednesday, April 30, 2003 11:37 AM
> To: [email-masked]
> Subject: Re: Working Group Last Call for
> draft-ietf-ospf-mib-update-06.txt
>
>
> Jeff Parker wrote:
> >>>What other TE stuff would we need?
> >>
> >> From a configuration standpoint, there is also TE color. From a
> >>monitoring standpoint, there is all the bandwidth state.
> How did ISIS
> >>handle this?
> >
> >
> > IS-IS doesn't configure TE information, anymore than it
> configures the
> > MTU.  It just finds stuff through some implementation
> dependant method
> > and reports it.
> >
> > This is visible through the LSP Database (Link State PDU, not Label
> > Switched Path) which allows someone to see what is being flooded.

Likewise for OSPF through the TE LSAs in the Area LSDB Table.

>
> Sounds reasonable. So why would we want to allow
> configuration or visibility of TE information in the OSPF MIB?

I think we might want to configure protocol-specific TE information
in the protocol MIBs and non-protocol-specific information in the TE MIB.
Both the IS-IS MIB and the updated OSPF MIB currently support the
configuration of the enabling/disabling of TE for the protocol.

isisSysLevelTEEnabled OBJECT-TYPE
        SYNTAX TruthValue
        MAX-ACCESS read-create
        STATUS current
        DESCRIPTION
            "Do we do Traffic Engineering at this level?"
        DEFVAL { false }
    ::= { isisSysLevelEntry 9 }

ospfTrafficEngineeringSupport OBJECT-TYPE
        SYNTAX       TruthValue
        MAX-ACCESS   read-write
        STATUS       current
        DESCRIPTION
           "The router's support for OSPF traffic engineering."
        ::= { ospfGeneralGroup 17 }

In the "Traffic Engineering Extensions to OSPF Version 2" document,
the traffic engineering metric sub-TLV seems to be specific to OSPF.
From section 2.5.5.

   "The Traffic Engineering Metric sub-TLV specifies the link metric for
   traffic engineering purposes.  This metric may be different than the
   standard OSPF link metric.  Typically, this metric is assigned by a
   network admistrator."

Similarly, the "IS-IS extensions for Traffic Engineering" document
defines sub-TLV 18.
From section 3.7.

   "This sub-TLV contains a 24-bit unsigned integer.  This metric is
   administratively assigned and can be used to present a differently
   weighted topology to traffic engineering SPF calculations."

As Don suggested, these might be candidates for a new configuration objects
in the protocol MIBs. Bandwidth, Admin Groups, etc. are covered in the TE
MIB.

-Dan

> Thanks,
> --
> Acee

---

From: Acee Lindem <[email-masked]>
Date: Wed, 30 Apr 2003 15:26:17 -0400

Daniel Joyal wrote:
> in the protocol MIBs. Bandwidth, Admin Groups, etc. are covered in the
> TE MIB.  draft-ietf-tewg-mib-04.txt

Okay - I'm not strongly opposed. However, I took a look at the
TE MIB (draft-ietf-tewg-mib-04.txt) and its tunnel table is relative
to a complete TE'ed path (e.g., LSP). Whereas, the OSPF TE stuff
applies to a specific interface. It almost seems to me like all this TE
stuff should be included or go in a separate MIB. The problem with
included it is that the extensions go on an on.

--
Acee

---

From: Rohit Dube <[email-masked]>
Date: Wed, 30 Apr 2003 15:40:03 -0400

On Wed, 30 Apr 2003 15:26:17 -0400 Acee Lindem writes:
=>> As Don suggested, these might be candidates for a new configuration objects
=>> in the protocol MIBs. Bandwidth, Admin Groups, etc. are covered in the
=>> TE MIB.  draft-ietf-tewg-mib-04.txt
=>
=>Okay - I'm not strongly opposed. However, I took a look at the
=>TE MIB (draft-ietf-tewg-mib-04.txt) and its tunnel table is relative
=>to a complete TE'ed path (e.g., LSP). Whereas, the OSPF TE stuff
=>applies to a specific interface. It almost seems to me like all this TE
=>stuff should be included or go in a separate MIB. The problem with
=>included it is that the extensions go on an on.

FWIW, I would be mildly opposed to putting the TE stuff into the MIB
for exactly the reasons that Acee suggests :
o if we decide to work on this, this should go into a separate MIB.
o TE extensions may go on for a while and we can't wait on these to
  push the ospf-mib-update through. For instance if the diffserv te
  work is standardized, there may be objects from there that would need
  to be pulled into such a MIB.

Regards,
--rohit.