Minutes from Policy Framework Working Group Meeting Sessions at Pittsburgh IETF: (Summary submitted by Ed Ellesson, Detailed Minutes by Andrea Westerinen and John Strassner) (Note: This summary is a reformatting of the Wrap-up charts put up at the end of the meetings in Pittsburgh.) 1. Except for a few editorial changes, there was consensus that the -07 PCIM draft is ready to go forward to proposed standard. Bob Moore is editing a -08 version as we speak, which will be out shortly. [Note: at an authors meeting later in the week, we also got some additional comments from the Security Area for the Security Considerations section, which we will also include in the draft that we send forward. We are considering this input as if it was received during the IETF last call period, since we believe it is important to the IESG's approval of the document.] 2. The PCLS draft will be revised again to address versioning questions, and input from the LDAP community regarding security aspects, so that conflict is avoided with the ldap standards direction. 3. The polterm draft will continue forward with the intention of becoming an fyi rfc. Expect further discussion on all the working group mailing lists whicha are dealing with policy. 4. The QOS Policy Info Model will be revised as a result of implementation experience. Now is the time to get your comments in. The comment period will extend through the end of August, after which a new revision is expected. The authors will be looking to advance the document at that time, so don't wait until then to influence the content! 5. There are questions about the QOS Device Info Model draft: (need discussion on the mailing list) -best way to do filter characterization -how to position relative to pib, mib and diffserv conceptual model -relationship to service elements, capabilities, and to qos policy draft and other documents need discussion on the list 6. MPLS, VPN and SLS: There is definite interest in the MPLS policy and related work being done in the policy framework working group. Questions remain (need discussion and proposals on the mailing list: -reusability of the classification mechanisms in the qos model -how to structure the work into the various working groups, and to order the work -levels of abstraction, instance level control, roles, trunk types, and signaling: -how to model, and what is in the realm of policy Policy Framework WG, Day One (Monday, July 31) Minutes recorded by Andrea Westerinen and John Strassner Agenda Bash ----------- Proposed agenda passed without comment. Bob Moore, Policy Core Information Model draft-ietf-policy-core-info-model-07.txt ---------------------------------------- The previous version (-06) was published in May 2000. It passed both working group and IETF last calls, and was submitted to the IESG for review. Harald Alvestrand did an extensive review and had comments. The current version (-07) is a response to many of Harald's issues. The most significant change was naming, especially CIM's naming conventions. The previous version made CIM naming a central part of the draft. However, the policy classes really was independent of these issues. The document now covers all of the naming required for the structure of policies, and a new appendix was introduced to contain naming rules specifically for use by a CIM object manager. This strengthens the draft, in that now we have naming rules for a truly independent policy structure, plus additional naming rules for interoperability with a CIM model. It simplifies naming, and also discusses how naming is used when communicating with a native CIM implementation. Other changes: 1. 2 associations removed - PolicyConditionSubject and PolicyConditionTarget. This is because they are Not needed for the current wave of PCIM applications and extensions, and because there is not yet a clear understanding of "subjects" and "targets". Thus, they were removed pending further clarification. 2. Abstract class ManagedElement was introduced at the top of the object hierarchy. If policies are indeed applicable to anything, we likely need associations that plug into the highest level of the hierarchy (e.g., subject and target). This also had the effect of raising some properties higher in the inheritance hierarchy, but no content was changed 3. Associations in model - Semantic overlaps existed between associations in the model and with some existing associations in CIM. Thus, the existing associations in policy were recast either as subclasses of existing CIM associations, or as subclasses of new abstract associations defined in PCIM. Again, none of the policy classes changed their semantics, but this enables us to exploit inheritance in the associations that we defined. Bert suggested and Bob agreed ... These changes are editorial in nature. Bert continued: Do people agree? If not just editorial comments, then we need another last call Ed: Is another last call needed? Silence is taken as acceptance Yoram Ramberg suggested that we relax the text in PCIM that restricted grouping policyGroups and policyRules in policyGroups, based on implementation experience. We agreed that we would do this as an editorial change. Bert: Can be removed in editing for final submission >From the wrapup on the first day: The working group is satisfied that the -07 PCIM draft is ready to go forward to proposed standard, including the feedback from the IESG review and editorial changes. Bob Moore, Status of Policy Core LDAP Schema draft-ietf-policy-core-schema-07.txt -------------------------------------------- The current version has also moved to an -07 revision, but it got there by a different path. The -06 was published in November 1999 and then work was held pending PCIM finalization. This is because it is a mapping of the Core Info Model, and we needed stability in PCIM before we continued to edit PCLS. The new -07 version was published 7/14/2000. The main change was that in parallel with the IETF work, the DMTF was also performing active work on mapping CIM to an LDAP implementation. Recall that CIM consists of a layered set of models. The DMTF published both a generic mapping guidelines document as well as 2 mapping documents for the Core and Physical models. All of these documents are still evolving and the mapping continues. The DMTF documents available on the DMTF site at: http://www.dmtf.org/spec/denh.html Our mapping was revised slightly to include this work. Specifically, there are now a set of real LDAP classes from which to subclass the Policy classes. The high-level CIM classes are registered with OIDs from the DMTF Enterprise subtree. PCLS pre-dates this DMTF mapping, and uses IETF OIDs for its specific classes. Mapping of associations. The DMTF recommends three ways for mapping CIM associations: - DN pointers in aux classes (attach a reference to a structural class) - Separate classes representing the associations - Implicit via DIT containment PCLS uses DN pointers in a structural class and DIT containment to map associations. CIM naming is mentioned in PCIM - In appendix in PCIM. However, there are the same set of issues in PCLS as there were in PCIM. These will be fixed in a similar manner. There are two different ways to produce an LDAP implementation. If you go from PCIM to PCLS directly, then you can take the policy content and map to a naming scheme that makes sense for a directory. On the other hand, if you have an actual CIM implementation, you do NOT want to use any arbitrary naming scheme, you NEED to use CIM naming. This is described in Appendix A of the PCIM. Furthermore, if you want interoperability between native CIM and native LDAP, then you need to map CIM names into the directory. So, each LDAP class has an attribute called orderedCimKeys, which represents CIM naming flattened into a directory string. Note that this can be left out if the implementation is not in a CIM environment. With respect to the directory naming that is defined in PCLS, we use cn (common name) for x.500 style naming, along with class-specific naming attributes (e.g., policyGroupName to name a policyGroup entry). We don't mandate the use of one or the other, as there is no consensus as to which attribute to use in directory implementations. All we can do is provide the tools. ;-) We also define DIT structure and content rules for naming via any of these approaches. ------------------------ John Strassner: Another addition is needed, which is to prefix each of the classes and attributes with a string to protect the schema against version changes Mark Wahl: Noticed that the DMTF mapping prefix used is "cim23" - Does this go through a last call similar to the IETF? Should it before we use it? John: Work in the IETF mapping was taken up by a dedicated sub-team in the DMTF, and expanded and clarified. Close to being finished in the DMTF and then will be brought back to the IETF for further discussion. This is an official document and can be properly referenced. Ed: We could have a single ID in the IETF with pointers. Or, just have normative references in the pertinent IDs. Mark Wahl: We are reviewing a mapping based on the DMTF guidelines. What if IETF comments indicate that a change is needed to the mappings or guidelines? Ed: Number of team members overlap groups. Expect these same folks to take this feedback back to the DMTF and affect change. Bob: Guidelines document is categorized as "living" and subject to evolution. The mappings that already exist, those are done. If we determine that they could have been done in a better way, then they would need a different label. Can we rely on them as unchanging, but can not rely on them always being the best thinking. Keith McCloghrie: Do we really want the cim23 numbering in the class names? What happens when you get to cim24? Bob: The answer is that we want "a" version in the name so that we can indicate different versions. Should the labeling be "23", "24" or some other labeling? Ed: Nothing to prevent us from changing the name of a class and creating the right LDAP basis for the policy classes. John: The current view of the subteam is to in fact change the prefix from "cimXY" to something else, because "cimXY" has semantics that tie us to a specific CIM version, which is undesirable. Mark Wahl: Mapping document includes text on discovering the schema and authenticating it. Should this be in one document? Or separate out applicability? Example - Kerberos but not digest. However, LDAP says that can use digest. Maybe an applicability document on how policy uses the directory may be valuable. Bob: Ed and Russ worked on security considerations. Ed: Tried to capture the best knowledge on how to use the directory. John: LDAP's Mandatory To Implement is digest. This conflicts. Need to separate guidelines from security. Mark agreed to help get this corrected. Bob: Next draft should not be too far in the future. ------------------------ >From the wrapup on the first day: PCLS will be revised once more to address versioning and the authors will work with Mark Wahl on applicability of current ldap direction on security, to avoid conflict. Andrea Westerinen, Policy Terminology Status -------------------------------------------- draft-ietf-policy-terminology-00.txt There have been several versions of policy terms that have been floating in the IETF. At the last IETF, it was decided that the Policy Framework working group would own this draft. Our goal was to document the terms that exist and to point out conflicts, as opposed to create new terms or creatively re-arranging terms. One example is the term "roles". It is currently defined differently in SNMPConf than it is in Policy, DiffServ, and RAP. Our job is to identify such conflicts and help bring the dissenting working groups to a consensus if possible. In building this new draft, our approach was to start with all existing terms that we could find from applicable drafts. We organized the document based on RFC 2828 (the Internet Security Glossary). All terms and their acronyms listed in alphabetical order. Each term is characterized as P (policy related), M (mechanism related, as in COPS, PIB, or DEN), or A (area of use for policy (for example, DiffServ). Further work will consist of minor updates and clarification to existing terms. We want to add a table to cross-reference the terms with the drafts that use those terms. We also need to resolve two conflicting terms: "role" (SNMPConf definition conflicts with the definition used in Policy, RAP, and DiffServ) and "role-combination" (slight confusion between how the PIB uses role-combination and how it is used in Policy) - the problem is that the PIB uses role-combinations in a more specific manner than Policy does. How does this affect existing documents? All affected documents are either drafts or at Proposed Standard, so both have to be revised in any case before they proceed. So hopefully the use of terms defined in this document will spread over more and more RFCs. We want to have a master table that cross-references the terms and where they are used in which drafts. However, there is a problem with having the cross-referencing table in an RFC. So one solution is to include it while it is progressing towards RFC status, and then remove the table when it reaches standards process. This is the approach that we will use. Andrea needs to send the info on the glossary to all pertinent mail lists. >From the wrapup on the first day: direction is as an fyi rfc, that is referenced by stds track docs. Will put email on the other affected mailing lists for expanded discussion. Yoram Snir, Status of QoS Policy Information Model & Schema draft-ietf-policy-qos-info-model-01.txt ----------------------------------------------------------- This version is the same as the version posted before Adelaide, and was previously revised under individual submissions before it became a working group draft. There have been no major comments received since Adelaide. The major changes in this version from the previous version inclue: - Extensions of variables and values - Rule decision strategy - Extended actions - PolicyRule associations (SDNs to association classes) - Object repository - Other cosmetic changes Everything that was done in the QoSPIM was as an extension to the PCIM. We identified many concepts, such as reusable objects and policy repositories, that eventually moved into the PCIM. These remain as general concepts to PCIM and are refined in the QoSPIM to reflect the particular semantics of QoS, as opposed to generic, policies. The QoSPIM also explicitly defined policy scope for applying policies. Specific policy conditions and actions for Diffserv and Intserv were developed in this draft. Conditions are defined as a {variable - operator - value} triplet. Predefined variables and their binding to acceptable values (e.g., you can't have an IPAddress value of -3) was defined, as well as a generic extension mechanism. A simple QoS policy condition was defined whose variable specifies the attribute of the flow that should be matched when evaluating the condition. Predefined variables and values were included as a class hierarchy, with corresponding values. This enables a binding to be established, and also simplifies its representation for many different types of data models. The binding also includes a generic mechanism for specifying some simple constraints. Two simple match strategies were defined - match-first and match-all. Examples of their use and their differences were included in the draft. It was noted that the match strategies should have their semantics defined and documented in Polterm. Two different types of QoS actions were specified - signaling and provisioning. The draft describes how meters, markers, shapers, and droppers could be implemented. It also uses the concept of traffic profiles to control the provisioning of these elements. The decision strategy is defined per qosPolicyDomain. The basic difference is that match-first evaluates all attributes according to priority until it finds one that matches and then exits. Match-all finds all that match, and then executes the actions of each matching condition. Note that these two strategies can be mixed as appropriate. The QoS Policy Schema also has not received any comments, but it needs to be held up so as to realign with the new PCLS that will be issued. ------------------------ Ed: Do we have any other implementations that could be brought to bear? Yoram Ramberg: We have an implementation. Dave Durham: Specifically when mapping to DiffServ conceptual model or QoS Device Model, that describe meters, markers, etc. - how are these combined? And used? What if I wanted to meter together FTP and xyz? Yoram: You would have two rules with the same action. Meters are actions. Bob: Do you need more synchronization changes given the new PCIM? Yoram: Some minor naming changes. John: Agreed, but these are really editorial in nature. Marcus Brunner: We have done similar things in MPLS for signaling. You now have RSVP signaling. Should we bring these together into a higher level signaling action? Yoram: You can certainly share actions but it is hard to combine things from different policy domains. Marcus Brunner: You reuse RSVP signaling in MPLS. Is this ok in the model? Yoram: Yes Walter: A meter has two or three different outputs. How do you do this as an action? Yoram: A meter is not an action. A meter is used with an action. It is used in association with a traffic profile - it can be discarded, reshaped, etc. Yoram: It's frustrating that this draft hasn't progressed in the absence of comments. Ed: Not clear that the group indicates that this is ready for last call. What are the issues? This is a model that applies Policy to QoS. This ties the DiffServ QoS to policy. Shai: Informational or proposed standard? Ed: Proposed standard. Ed: Let's take a straw poll. (Results of the straw poll indicate that the vast majority have no opinion.) Ed: People who voted to not go to last call - could you put your issues on the list? People who didn't vote - you might want to indicate why you didn't vote. Kathy Dally: Variables should be part of the Core Schema. Question in Adelaide as to how this would be done and put into CIM. What is the status? John: In Adelaide, it was suggested that variables, values and binding be moved to Core or to a separate document. This was because it was suggested that there was more applicability of these concepts than just to QoS. Reason that this was not done was because there was no clear consensus on either doing this, or which option to choose. So, we decided to keep these concepts in the QoSPIM for now in order to encourage specific implementation experience in a specific domain before we try to generalize these concepts. Ed: You often classify a packet based on the same criteria independent of QoS or IPsec. Do we want this generalization? Feedback indicates that we can't generalize. What do any implementation experience indicate? Lee Rafalow: I did not raise my hand - pro or con - since I think that we need more time to think about this. Joel Halpern: We are having this discussion in various other WGs. DiffSErv MIB vs MPLS MIB have different classifiers. Putting up as a proposed standard - one particular piece of this problem seems the wrong thing. We need to wait on the other WGs. Bob: I think that the Core policy is too high conceptually to target these structures. There might be an intermediate document if you think about everything that policy can apply to. Ed: Question is really "do we need to wait on this document?" Not whether we want to move things to Core. Keith McCloghrie: Can we apply this work to what is happening in MPLS? Ed: More discussion on MPLS tomorrow. We can revisit it then. Ron Cohen: Frustration about this draft. It has been out there for more than 6 months. I think that the right thing should be to put this on the mail list. Ed: We are not making the call here, but it will go to the mail list. John: Authors are requesting specific reasons on the mail list. Bert: Everyone who raised his/her hand that this should not go to last call - post to the list. ------------------------ >From the wrapup on the first day: it was noted that any objections over taking this document to working group last call should be posted to the list in the next 3 weeks. Policy Framework WG, Day Two (Tuesday, August 1) Minutes recorded by Andrea Westerinen and John Strassner Agenda Bashing - No change Andrea Westerinen, QoS Device Info Model draft-ietf-policy-qos-device-info-model-01.txt ---------------------------------------------- There are a long list of changes from the -00 to the -01 draft. Here are the major ones. There were no associations in the 00 draft - So much of the context for using the model was missing. Associations completely specified in the -01 version (13 associations not counting superclasses :-). QoSService capabilities properties removed pending further discussion. Statistics classes removed pending further discussion and more stability in the MIBs. PrecedenceService changed from subclass of DiffServ to peer. ServiceTime class removed since its semantics are in PCIM (PolicyTimePeriodCondition and the PolicyRuleValidityPeriod association). The TCB class and its semantics were removed and replaced with ConditioningService and its semantics (e.g., the NextService association, tracking of the TrafficClass property across all of the conditioning elements, etc.). Added property (CanRemark boolean) to MarkerService Removed HeadTailDropper class since it provided no additional detail beyond the Dropper superclass. Removed PercentageDropper and moved its functionality to REDDropperService. Moved the semantics of the FailAction and SucceedAction properties in MeterService, to a property on the NextServiceAfterMeter association (MeterResult). This conveys individual traffic flows for (up to) a 3 level meter. Also corrected EWMAMeter to better align with the conceptual model. Moved IsIngress from ClassifierService to a property on the ConditioningServiceOnEndpoint association. This enables us to identify the first and last conditioining services for a flow. Removed Status on ClassifierService and replaced with the HasClassifiedPackets property. This clarifies semantics for when packets have been classified. Moved TrafficClass from ClassifierService to a property on the NextService association to better describe the flow of traffic through any of the ConditioningServices. In the model, we make a specific association between this property and similar properties in each conditioning service, so one can easily track what is happening on a flow-by-flow basis. Documented FilterList and FilterEntry (they were referenced but not defined in the -00 version). Also, in response to feedback from IPSP, we defined a new superclass for FilterEntry, called FilterEntryBase. This enables technology-specific mechanisms (e.g., DiffServ vs. IPSec) to define their own filters but use other parts of this model (e.g., the classifier). Added TrafficClass property on FilterEntry and tied it to NextService's TrafficClass property. Removed FilterType property of FilterList since it did not align with IPsec usage. Finally, added implied associations of FilterList and FilterEntry to the ComputerSystem class. Removed PrecedenceValue property in EFService, as this needs more clarification. Moved Enabled property on ForwardingService to ConditioningService. Removed ID property on ForwardingService - Was "Yet Another Name". We changed the name of BufferManagerService to BufferPool since the semantics of this class describe the pool of buffers and not the service. This meant that the class inheritance changed and properties were added. We added FIFO queuing to QueuingService enumeration. We removed the GiveExcessCapacity property from the PacketSchedulingService. Finally, we updated the QueuingService class hierarchy names for consistency. The salient features of the information model was then reviewed. Filters were discussed, and the properties of each class were explained. ------------------------ Question: Why are filters defined in this model and not in the other models? John: They're not in PCIM because not all policies need the concept of filters. The QoSPIM use of filters is at a much higher level. The next revision of this draft will bind the use of filters and other conditioning elements more tightly to the QoSPIM. QoSService is used to conceptualize a service as a set of coordinated sub-services that each need QoS. It serves as a common base class for defining sub-services needed to build higher-level QoS (e.g., the infamous "Gold Service" can be described as a set of sub-services that each have their own requirements. It therefore serves to consolidate relationships between different types of QoS services and the different types of "ConditioningServices" that each requires. The subclasses of QoSService enable the administrator's approach to defining QoS to be maintained. These three classes enable QoS to be expressed in terms appropriate to the technology being used - ToS, DiffServ, or 802.1P. ConditioningService defines how traffic is conditioned in the data forwarding path of a device. Subclasses of ConditioningService define the particular type of traffic conditioning being provided. Five fundamental types are defined: classification, metering, marking, dropping, and queuing. There are two important associations that are defined that provide additional semantics for these five types of conditioining services. These are the NextService and ConditioningServiceOnEndpoint associations. The NextService association indicates the specific sequence of ConditioningServices that are used to condition a specific flow or aggregate. Both one-to-one and different fan in/fan out relationships are described through the use of appropriate cardinalities on the association. It is a special type of Dependency association, but has an additional key property required (TrafficClass). This enables a ConditioningService to forward multiple traffic flows to the same 'next' Service while maintaining their traffic 'identity'. The ConditioningServiceOnEndpoint association decribes the Ingress/Egress points to a set of ConditioningServices. The PacketScheduling class hierarchy is a direct subclass of ForwardingService, and describes different scheduling algorithms that are used to service queues. This is defined in the SchedulerUsed association. Question: Why is a scheduler not a conditioning service, because it can also contain a shaper? Walter: Because we have defined a scheduler strictly as a dequeuing mechanism. In addition, there are relationships between each of the conditioning services, and the conditioning services represent the ability to condition traffic between each instance between ingress and egress. An example of using QoSService and its subclasses and associations was provided. Basically, higher-level concepts are represented through instances of the QoSService class. This can be used to define different technology-based QoS mechanisms (e.g., DiffServ vs. 802.1P) that will be used to implement the traffic conditioning required. These relationships are bound by the QoSSubService aggregation. We then use the QoSConditioningSubService aggregation to define the specific conditioning that will be used to implement that service. In other words, this aggregation specifies the particular ConditioningService instances that are required to implement a given QoSService. Question - how does this relate to the PIB and MIB, as well as PCIM and QoSPIM? Are these classes supposed to go in the policy repository? Andrea: No, this is an information model and is independent of the specific type of repository and access protocol that is being used. Walter: The policy "I want to limit traffic to 30%" may be a valid policy, but it doesn't describe how a policy server is going to use this policy, and it doesn't guarantee interoperability between policy servers. You have a policy that is mechanism-independent, but non-interoperable. Therefore, we tried to describe mechanism-dependent policies. John: Does this draft really depend on the MIB and the PIB? The authors think no, because this is an information model, and is by definition more generic than either the MIB or the PIB. Those are two implementations of a specific type of data model, and there may be others. The point is that not all information needs to go into all mappings. This is why the MIB and the PIB are not strictly dependent on this model, and do not need to be held up. ------------------------ Further work to do for the next revision of this draft: - Need to add IntServ and signaled QoS - Need to add statistics information back in - Discussion on the list as to whether we need more specific subclassing to indicate common scenarios, versus the flexibility of NextService and ConditioningServiceOnEndpoint - More information on cross dependencies of NextServices (for example, a meter dependent on queue depth) - Tighter alignment with PCIM and QoSPIM - Tie classifiers to physical ports - Updates based on recent discussions on Diffserv related to token bucket meters and other classes - Additions to enumerations (e.g., vlan id in Marker) Ritu Chadha, Policy Info Model for MPLS traffic engineering draft-chadha-policy-mpls-te-00.txt ----------------------------------------------------------- Info model based on PCIM Actions defined to manipulate trunks, LSPs, resource profiles and the associations between them. This is related o work from isoyama (lower level of abstractions). Where they are focused on LSP setup, and mapping to LSPs, this draft emphasizes CR-LDP. It is also related to the Wright draft, in that both define Load balancing. This is an info model for adaptive feedback control. Performance feedback to PDP - which gets its policies from repositories and communicates with PEPs. It defines the concept of traffic trunks, which are aggregations of traffic flows, placed in LSPs. The model manipulates abstractions associated with trunks such as affinity, preemption, priority, etc. Trunks are associated with the LSPs to which they are mapped, with backups. Network resources are attributes associated with a trunk. Route specification is also associated with a trunk. LSP "MPLSrealizes" association to the Route that it implements. Other associations also defined. No new policy conditions defined over what is in the QoS Policy Info Model. Reused QosPolicySimpleCondition, but defined a set of new Policy Actions - MPLSActivateTT, ModifyTT, DestroyTT, CreateLSP, etc. Next steps - Merge work with other drafts - Address naming issues - Info on how to fit in with a global policy object model, including domains, policy groups, and policy repositories - LDAP mapping - Find a home ;-) Marcus Brunner, QoS Info Model for MPLS draft-isoyama-policy-mpls-info-model-00.txt ------------------------------------------- Motiviation is to provide policy based management of MPLS networks. High level support and automation of traffic engineering. Followed Wright. Requirements similar to other authors. Objects and associations are labels which pass through the network. Traffic profiles, resource classes, explicit routes. Also defined label lifecycle - setup, update, and release LSPs. Associate traffic with LSP. There is signaling control of CR-LDP. This draft models the modification of the signaling parameter, and issues notification and release. It contains fewer actions than other drafts. Summary - The draft covers: - Lifecycle of LSPs - Mapping of traffic to LSP - Signaling control - QoS and MPLS - Fulfills requirements of Wright - Is simple and extensible - No backup LSP, no bidirectional trunk, no trunk signaling - Concept of FEC vs traffic trunk (from Ritu's draft) - 4 actions vs 7 actions (in Ritu's draft) ------------------------ Joel Halpern: I understand the space that we are working in and understand some of this as policy. The question is how you map traffic (TT, ATM VCs, etc.). This is a policy level question much as we talk about giving service to customers. We put in indirection. We talk about assigning roles to represent properties - and assign policy based on roles. Is there an assumption about trunks with roles or something equivalent? It seems that there is no decomposition or indirection but explicitly routed trunks. This is at an instance level and not an abstracted level. Are we distorting our tools to work at the instance level versus the abstracted one? Marcus: We are trying to model the network. It would be easy to have policies "all LSPs which belong to ResClass 1" then do some action. Joel Halpern: Should this be where we start versus talking at the low level right away? Marcus: We have this problem now. Why should we talk about high or low level? Shai Herzog: I agree with Joel. We are jumping the gun into the specifics of the mechanics of how to implement policy inside an MPLS network. What we haven't done is stay at the policy level - what are the requirements of policy in an MPLS network? What do you apply policy to? I agree that it is premature to build the low level building blocks. Ritu: We need to do more work with roles. This is missing in the drafts. We have the concept of resource classes, affinities, etc. This needs more work. Joel Halpern: Some of this belongs in policy and some in a network information model. ------------------------ Steven Wright - 3 drafts draft -wright-mpls-* ------------------------ Started discussion of MPLS policy mgmt to gauge WG interest. Goal was to match controls, concepts in MPLS with policy. Focus of work transferred to wright-mpls-te-policy and cops-mpls. Te-policy - Followup on previous, traffic engineering in policy context draft-wright-mpls-te-policy-00.txt - Example of policy-based management approach to TE using MPLS - Range of potential polices related to load balancing - Guide for producing a PIB - Assumes existing LSPs (no setup, LSPs must exist already) - Load-balancing - From traffic engineering WG - Influence TE guys to use policy for optimization - Time or network state dependent, offline or online, centralized or distributed, prescriptive or descriptive Load-distribution - Address comments from TE WG for broader discussion draft-wright-load-distribution-00.txt Presented in TE WG. This contains mechanisms that affect load distribution. 3 drafts targeted at te wg and for PIB guidance COPS draft is draft-franr-mpls-cops-00.txt Policy WG - Should be aware of the policy application to MPLS/TE and possibly coordinate policy efforts in other functional areas. TE focused on operations, not developing PIBs. Would expect MPLS guys to define a PIB IP VPN PIM - Mahadevan Iyer draft-iyer-policy-ipvpn-info-model-00.txt ----------------------------------------- Would like to understand how to move forward and overlap with work in other groups Motivation - Working with carriers who turn in requests for IP VPNs, Secure LANs, flexible address spaces, better mgmt of pipes, Security for traffic on the pipe, etc. This in turn provides requirements map to firewalls, QoS, NAT, IPsec. The mapping is one of how to enforce policy. Found that when we create multi-functional box - need to consolidate info models from various domains. This was driven externally, through finding vendors with policy enforcers and servers. This in turn requires us to have a common understanding of info model to integrate. Key aspects - Policy model/tags to mask the types and specifics of conditions. Example: Network condition that deals with layer2 tag. IP VPN policy sets in a domain translates as a set of policies that should be applied to a specific class of traffic. For enforcement, signaling and admin (in IPVPMPolicyDomain). IPVPN Condition types (common blocks) - reused policy conditions, but applied to network, users, application, enforcer, time IP VPN Action types include FW, NAT, QoS, Security. Each implementation/domain brings in its own action types. Draft does not redefine attributes of action class for these attributes. Goal of this draft is to be a policy umbrella Issues - Outside the current scope of the group - Individual action models are not ready - Going forward, need to decide on whether a consolidated policy model belongs here - What do we need to add/drop? Are the levels of definition in action models correct? Want to work on refining the draft, and request specific comments on structure and deficiencies. This could be an individual draft, but brings to my mind the purpose of the Policy Framework WG. It is not so much an exact implementation, but rather provides a policy umbrella to plug into Ed: Would like to come back to question of what this group should be concentrating on now and in the future. SLS - Yves T'joens Draft-tequila-diffserv-sls-00.txt --------------------------------- Submitted to diffserv and redirected to operational area. ADs thought that it fit better in Policy FW. Template for SLS suitable for negotiation at two levels: customer-provider and provider-provider boundary. Early idea on requirements on the negotiation protocol. Is there a home for this at the IETF? If not, need BOF in San Diego Assume a Customer Premise Network and two ISPs. SLSes are fed to the system and then translated to specific policies and fed to PEPs. So why is this needed? In order to allow automated and dynamic negotiation of SLSes. At customer premise/ISP boundary and IPS/ISP boundary, this enables the design of bandwidth broker functionality (regardless of whether centralized or distributed, and is applicable to both multivendor and multidomain problems. SLS - Scope (ingress/egress), flow, traffic conformance testing, and excess treatment. At network level - performance guarantees, quantitative and qualitative service schedule Virutal leased line, minimum rate guarantee with allowed excess, qualitative Olympic, funnel service (Services as examples). Interest in BOF? Objectives to specify info and semantics List requirements on negotiation protocol EC IST projects - TEQUILA, Internet 2 Qbone, DMTF SLA WG Sls@ist-tequila.org www.ist-tequila.org General wrapup on the MPLS and SLS drafts. Ed: Where do we go from here? Are there guidelines that we should be using? We need a common principle. John: Ed and I reviewed the drafts and believe that MPLS is very important. However, in the info model that we have, MPLS would be defined as a Service. But, this basic concept has not yet been modeled in any of the drafts. In other words, we are trying to control MPLS without defining the underlying application. We need policy and infrastructure that controls the application of the MPLS service and the implementation of MPLS mechanisms. With respect to the SLS draft, I am puzzled why this is not in DiffServ. The SLS draft very quickly needs policy to determine how bandwidths are distributed - but need infrastructure on the things being controlled before we have policy. Brian Carpenter: Why these drafts fit in operations and management seems clear. But why in policy is unclear. Bert: When this got referred to us, we agreed that it was an operation issue. I did not have time to read the draft, but SLS seemed to be based on policy. So, the discussion was to see if there is a fit, not to mandate one. The WG needs to consider whether it wants to take on this work after it finishes the current milestones. These need to be met first. Mahadevan: Do you agree or disagree? I would like to know where to go with this. Does this work fit within the scope of this WG? Ed: Not today. I am not sure if we can decide this today. There is the concern that John expressed with respect to the modeling of Services. We manage devices so that they can provide services. I do not think that we should define the services in this WG. Lee Rafalow: There is clear overlap with Iyer's work and what is going on in IP Security Policy. But, although we don't have Services defined, we seem to be continuing work on MPLS without it. Now, we may need it. There are parallels in IPSP and both IPVPN and SLS. This group may play a role if we want to wear an architecture hat. This is hard but there may be value in it. Steven Wright: A lot of what we talked about is nice and useful. But the part that is absent is how to tie this to actual users, customers, and business process. I need to tie this to business processes or it does not buy me anything. Iyer: This has come from work on a policy enforcer and policy server. I have avoided implementation details - down to individual queues - but I could do this. (From the floor) Is it fair game for the MPLS authors to merge their documents and submit it to this WG? Ed: This is a question to Bert. Is this allowed given our scope? Bert: I don't hear consensus that this is in our scope in the future. I hope by that time that we have moved on our other milestones. Ask the work group about fitting this into the charter. Ed: Who thinks that MPLS work fits in the Policy Framework charter? Majority agreed. Bert: Seems that that authors should get together and resubmit. (From the floor): We need a common document that identifies policy elements and problems. What needs to be enforced and handled in policy infrastructure? Policy oriented versus application oriented. Ed: There are elements in the current drafts that apply and should be amplified. If you look at MPLS, we can identify something that is policy itself but is really something to set up traffic. We need to identify what policy should be enforced and handled. (From the floor): Need to set up boundaries between this work group and others dealing with the protocols. There are lots of details and implementation experience. For example, MIBs are defined in the individual groups and not in an overall "SNMP" group. - MPLS Discussion Wrap-up by Ed Ellesson - Are any of the classification mechanisms reusable from QoS? - Which WGs should be involved in this work? - What are the relationships to services and infrastructure models? - How do roles fit into MPLS? - Where is signaling? - Need to reconcile the drafts - What is the right policy level and what level is linked to individual instance control? - What is the correct level of abstraction? - What are the requirements? - What are the Policy Framework WG charter updates? Ed Ellesson ed_ellesson@tivoli.com