Subject: Preliminary comments on draft-chadha-policy-mpls-te-00.txt

From: Yoram Ramberg <[email-masked]>
Date: Thu, 20 Jul 2000 18:09:41 -0500

Ritu, Huai-An and all -

Great job! Your draft is well crafted and very clear. It's quite rare to 
see techies who can also write...

I've done a quick review of this document and have a couple of comments.

I'll limit my comments to the actual technical policy specification part as 
I'm a very little expert on MPLS. So most of my comments refer to the class 
definition itself.

Also, due to time constraints, I've only done a partial review. So these 
are just a couple of things I stumbled over. I'm sure there will be more 
comments from others, feeling in the holes that I left.

Now -

1. While this is addressed in part in the usage examples, it would be good 
to add text explaining how this object model fits in with a global policy 
object model in a practical, real life situation. In such a situation there 
will be a data tree made up of domains, policy groups, repositories and 
such. Should there be a chart and/or text describing this?

2. Naming:

- Throughout the class definition each action class contains a name 
property. I think this may not be necessary because there's an elaborate 
naming mechanism already built into PolicyAction.

- In some cases, when a class is derived from the Policy abstract class, it 
may be necessary to consider a name attribute, but please consult section 
5.3 of the core inf. model for naming guidelines.

3. Multiple property definitions: Some properties are multiply defined -- 
Why? It appears that once you defined  the mpTrafficTrunk reference 
property you don't need to redefine it every time it is used. The 'Name' 
property is also multiply defined but as I said above, it may not be 
necessary at all.

4. In general, it would be good to specify which properties are 'MUST' and 
which are merely 'MAY'. For example. it seems that the inf. model has 
several '*' associations. In such cases the reference property should be a 
'MAY' property.

5. Referring to the MPLSResourceProfile class. Aren't these two PR traffic 
profiles? Say, mpInPolicer and mpOutPolicer, both referencing an instance 
of qosPolicyPRTrfcProf. Now, here's a good place to use the core style 
association classes (similar to MPLSHopInRoute and such) -- this is 
particularly important for an LDAP schema (assuming one would be created 
for this inf. model). Details can be made available upon request.] In any 
event, these should be references to reusable objects (IMO).

6. Referring to the association of MPLSTrafficTrunk and 
qosPolicyPRTrfcProf. I'm not too sure about that, but why limit yourself to 
the policer? Another approach would associate a trunk with a general PR 
action including a meter (with an interface scope) and such? Am I wrong on 
this?

7. Do you happen to have (or are willing to create) a UML chart in a format 
that's easier on the eye (Visio or such)? ASCII art is the standard but not 
always clear enough.

Cheers,
*Yoram