Subject: Re: Policy Information Model for MPLS Traffic Engineering

From: Ritu Chadha <[email-masked]>
Date: Mon, 17 Jul 2000 17:44:07 -0400 (EDT)

Tom,
Comments inline.

>         Hi Ritu,
>
>         My comments are inline:
>
>> >       A few questions about your draft.
>> >
>> >       1) How does this draft differ from say the use
>> >               of COPS and the definition of a PIB
>> >               instead of using the object model?
>>
>>The information model in our draft would be used to describe policies
>>that a PDP would implement, in accordance with the policy framework.
>>The PDP could implement the policies via COPS and appropriate PIBs.
>>Appropriate PIBS could very well be defined based on some of the
>>information presented in our model.
>
>         I disagree. This is what the PIB should be used for.
>The object model you define could very well be done by
>a proprietary vendor. I don't see the need or advantage
>to do so in a standard way. What advantages do you see of
>defining such an object model versus using say, a PIB
>and COPS to define and implement policy for MPLS?

The definition of such policy information models is the
whole raison d'etre of the Policy Framework WG. The following
snippet from "Requirements for a Policy Management System",
draft-ietf-policy-req-01.txt,
summarizes the need for a standardized common information model:

   "...centralized management leads to the
   need for a repository; scalability requires a means to  commu-
   nicate the data beyond the repository; abstraction requires a
   common information model; automation requires the  abstraction
   and components to perform actions based on management data and
   real-time inputs.

Please refer to the above draft for details.

The charter of the policy WG states clearly that one must be able
to translate high-level policy information into device configuration
information. This will require coordination with MIB and PIB development
work because, as you correctly point out, ultimately the devices
will be configured using COPS/SNMP/etc. 

A related document ("Policy-Based Load-Balancing in 
Traffic-Engineered MPLS Networks", draft-wright-mpls-te-policy-00.txt)
also aims to provide guidance for the development of a PIB for
MPLS based on a policy information model. 

>
>> >       2) It is not clear to me whether or not it is your
>> >               intent to make this object model useful
>> >               for both MPLS network management or just
>> >               only for off-line TE. It seems from reading
>> >               your document that your intent is to do
>> >               both.
>> >
>>
>>That's correct; the intent is to be able to do both.
>
>         In terms of device management, is it then your
>assertion that the MIBs will need to be re-aligned to fit
>in with your object model in order to do device-level
>management? As I see it, I don't see how the MIBs as they
>are defined today, fit in with your object model. If anything,
>I think that the object model should be changed to reflect
>that which is defined in the MIBs.

No; there should be a way to map from the policy information
model to the appropriate MIBs/PIBs, but I don't see a need to
re-align the MIBs. I disagree with your statement that current
MIBs do not fit in with our object model; we have based some
of our LSP model on the MPLS TE MIB as noted in our draft.
Since there are currently no MPLS TE PIBs defined, I can't
comment on the required re-alignment there.
If it turns out that there is a fundamental misalignment and
that there is no way to map from our information model to
existing MIBs, then we may need to revise our information
model. We plan to do this as the relevant MIBs mature and
PIBs are defined.

>         --Tom

Ritu

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 17 Jul 2000 22:30:29 -0400

Hi,

>summarizes the need for a standardized common information model:

         I thought that the purpose of the MPLS WG was to define
protocols (and MIBs to manage them) not policy, but I may be
mistaken here. ;) I can understand holding topological information
or such network-wide things, but the inclusion of other information
into this standard object model seems redundant, doesn't it?
Isn't this why we have the MIBs and PIBs? That is, to define
what is manageable, and how some of those managed objects are
provisioned via a defined policy?  Why should we spend time
defining an object model which has basically already been
defined for MPLS?

         --Tom

---

From: Marcus Brunner <[email-masked]>
Date: Tue, 18 Jul 2000 10:12:34 +0200

Tom,

At least our draft (draft-isoyama-policy-mpls-info-model-00.txt) is
intend to go into the policy working group. In a later stage, e.g., for
the definition of a MPLS PIB, the situation may change.

Marcus

-- 

Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

New address starting 9/1/2000
Postal Mail:
Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 905110
Fax:   +49 (0)6221/ 9051155

Address valid until 8/31/2000
Postal Mail:
Hardenbergplatz 2
D-10623 Berlin
Germany

Phone:  +49 (0)30/ 25 42 30 17
Fax:    +49 (0)30/ 25 42 30 99