Subject: RE: Policy issues: definition of Roles

From: Andrew Smith <[email-masked]>
Date: Mon, 7 Feb 2000 15:07:55 -0800

Shai,

In the worst case then, yes, you're right, the PDP has to multiply out the
role combinations and send them all to the PEP. But there will be many cases
where the PDP knows that a policy does not need to distinguish between "T1"
and "Ethernet": then, the PDP can download a policy for role-combination
"Edge". In that case, the ALL in your definition is not applicable. That is
what I was trying to explain in my response to Bob Natale last week (1/31).

Andrew

> From: Shai Herzog [mailto:[email-masked]]
> Sent: Sunday, February 06, 2000 8:48 PM
> To: John C. Strassner; Andrew Smith; 'Ken Roberts'
> Cc: [email-masked]; [email-masked]'; [email-masked]
> Subject: RE: Policy issues: definition of Roles
> 
...
> 
> 4. PDPs may be smart enough to merge roles (and therefore deal with
>     individual roles within a role combination). This is actually
>     an implication of observation (2) but I though it needs to be
>     clarified.
> 
>     For example, in the PDP, lets assume Ethernets get special
>     treatment (higher precedence rule).
> 
>     Role=Edge    : If Service=Gold then Mark DSCP=xxx
>     Role=Ethernet: If Service=Gold then Mark DSCP=yyy
> 
>     This will produce the following configuration (using 
> COPS, or equiv):
> 
>     Role=Edge+Ethernet: Mark (Traffic Desc) DSCP=yyy
>     Role=Edge+T1      : Mark (Traffic Desc) DSCP=xxx
> 
> So, going back to the definition I gave a while back, the reason for
> the "ALL" comes from observation 3.
> 
> PDPs can process policy whatever the hell they wish (within reason)
> but they have to respond to the PEP with specific policy for each
> COMPLETE role combination, and cannot respond to partial role
> combination or a specific role which is only a part of a role
> combination.

---

From: Shai Herzog <[email-masked]>
Date: Tue, 08 Feb 2000 15:32:13 -0500

>what I was trying to explain in my response to Bob Natale last week (1/31).

I think I am beginning to understand what you mean... ;-)

with two Role Combinations "Edge+Ethernet" and "Edge+T1" the PDP
normally would send two different configurations such as

"Edge+T1":    Mark DSCP AF21
"Edge+Ether": Mark DSCP AF11

If it turns out that the instructions for these two are the same
(by chance) meaning (Policy1):

"Edge+T1":    Mark DSCP AF11
"Edge+Ether": Mark DSCP AF11

Then perhaps we'd want to have a wildcard that says (Policy2):

"Edge+*":     Mark DSCP AF11

BUT, Policy2 is merely a short hand for Policy1 but they mean the same.
The important distinction in my view is that the PDP cannot send
a policy "T1+*" and expect the PEP to merge the policy
in "Edge+*" with "T1+*" into "Edge+T1".

So, when receiving a policy for "Edge+*" the PEP interprets it
as

"Replace/override the policy for all role combinations with Edge
in them with the following"...

If a "T1+*" comes later, it will REPLACE (not merge) the configuration
installed on "Edge+T1".

This is why I insist on the "ALL" in the role combination: The PDP
must provide a policy that is clearly for a specific COMPLETE
role combination, and the PEP isn't expected to merge policy
for roles into role combination. BUT as you suggested a shorthand
representation may be made for the purpose of saving bits and overhead
but that has the same meaning as the "ALL".

I am not sure if my description is clear, but I hope ;-)

Shai

__________________________________________________________________
Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
55 New York Avenue                            Main: (508) 620-1141
Framingham, MA 01701                          Fax : (212) 656-1006

---

From: "Jon Sjoberg" <[email-masked]>
Date: Wed, 9 Feb 2000 05:59:00 -0800

Shai,

Correct me if I'm wrong, but I read the below to say that the "ALL" in your
definition means that all the roles in a role combination associated to a
policy must be a proper subset of the roles on a PEP for the policy to be
loaded.

So, for your example:

If I had a QoS policy P1 associated with the combination "Edge+Ethernet",
and a PEP that supported the roles
"Edge+Ethernet+TrustedInterface+Engineering", then P1 would be appropriate
for that PEP.  Correct?

In this case, a security policy, P2, for all TrustedInterface PEPs would be
merged with P1.  Correct?

What I'm also understanding that may be wrong is that this position further
holds that the association between Edge+Ethernet and P1 is not stored in the
schema but the PDP comes up with this out of some learned or intrinsic
network knowledge (proprietary).  What is stored in the schema, and
associated with a policy in the schema, is some set of identifiers as to the
general functionality that a policy pertains to (Configuration, QoS,
Security, etc.).

Am I close?

Jon
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Shai Herzog
  Sent: Tuesday, February 08, 2000 12:32 PM
  To: Andrew Smith
  Cc: [email-masked]; [email-masked]'; [email-masked]
  Subject: RE: Policy issues: definition of Roles

    Shai,

    In the worst case then, yes, you're right, the PDP has to multiply out
the
    role combinations and send them all to the PEP. But there will be many
cases
    where the PDP knows that a policy does not need to distinguish between
"T1"
    and "Ethernet": then, the PDP can download a policy for role-combination
    "Edge". In that case, the ALL in your definition is not applicable. That
is
    what I was trying to explain in my response to Bob Natale last week
(1/31).

  "Edge+*":     Mark DSCP AF11

  Shai

---

From: Shai Herzog <[email-masked]>
Date: Fri, 11 Feb 2000 08:58:51 -0500

At 05:59 AM 02/09/2000, Jon Sjoberg wrote:
>Shai,
>
>Correct me if I'm wrong, but I read the below to say that the "ALL" in 
>your definition means that all the roles in a role combination associated 
>to a policy must be a proper subset of the roles on a PEP for the policy 
>to be loaded.
>
>So, for your example:
>
>In this case, a security policy, P2, for all TrustedInterface PEPs would 
>be merged with P1.  Correct?

This is too vague, what do you mean by "associated" so you mean that
it is sent to the PEP with the role "Edge+Ethernet", or do you
mean that it is associated in the policy DB? I must understand the
level your talking about.

>  What I'm also understanding that may be wrong is that this position 
> further holds that the association between Edge+Ethernet and P1 is not 
> stored in the schema but the PDP comes up with this out of some learned 
> or intrinsic network knowledge (proprietary).  What is stored in the 
> schema, and associated with a policy in the schema, is some set of 
> identifiers as to the general functionality that a policy pertains to 
> (Configuration, QoS, Security, etc.).
>
>Am I close?
>
>Jon
>>From: [email-masked] 
>>[mailto:[email-masked]]On Behalf Of Shai Herzog

---

From: "Jon Sjoberg" <[email-masked]>
Date: Fri, 11 Feb 2000 11:22:59 -0500

I mean logically associated with it, whether we store this association in
the DB or not seems to be under discussion.  So P1 is destined for any PEP
that supports "Edge+Ethernet" and P2 is destined for any PEP that supports a
TrustedInterface.

  -----Original Message-----
  From: Shai Herzog [mailto:[email-masked]]
  Sent: Friday, February 11, 2000 8:59 AM
  To: Jon Sjoberg; Andrew Smith
  Cc: [email-masked]; [email-masked]; [email-masked]
  Subject: RE: Policy issues: definition of Roles

    Shai,

    Correct me if I'm wrong, but I read the below to say that the "ALL" in
your definition means that all the roles in a role combination associated to
a policy must be a proper subset of the roles on a PEP for the policy to be
loaded.

    So, for your example:

    If I had a QoS policy P1 associated with the combination
"Edge+Ethernet", and a PEP that supported the roles
"Edge+Ethernet+TrustedInterface+Engineering", then P1 would be appropriate
for that PEP.  Correct?

     What I'm also understanding that may be wrong is that this position
further holds that the association between Edge+Ethernet and P1 is not
stored in the schema but the PDP comes up with this out of some learned or
intrinsic network knowledge (proprietary).  What is stored in the schema,
and associated with a policy in the schema, is some set of identifiers as to
the general functionality that a policy pertains to (Configuration, QoS,
Security, etc.).

    Am I close?

    Jon

      -----Original Message-----

        Shai,

        In the worst case then, yes, you're right, the PDP has to multiply
out the
        role combinations and send them all to the PEP. But there will be
many cases
        where the PDP knows that a policy does not need to distinguish
between "T1"
        and "Ethernet": then, the PDP can download a policy for
role-combination
        "Edge". In that case, the ALL in your definition is not applicable.
That is
        what I was trying to explain in my response to Bob Natale last week
(1/31).

      "Edge+*":     Mark DSCP AF11

      BUT, Policy2 is merely a short hand for Policy1 but they mean the
same.
      The important distinction in my view is that the PDP cannot send
      a policy "T1+*" and expect the PEP to merge the policy
      in "Edge+*" with "T1+*" into "Edge+T1".

      Shai

---

From: Shai Herzog <[email-masked]>
Date: Fri, 11 Feb 2000 12:19:49 -0500

Missed the point. "logically" is exactly why I am confused by your
example. You have to be more precise since there are multiple levels
of policy each with its own "logical" stuff.

I guess I'll ask this as a yes/no question:

Is this association a decision by the PDP? (or a schema style association?)
Are P1 and P2 mergable at all (from the same policy domain) or are they 
separate (orthogonal) one?
In your example, it seem that they are NOT from the same domain
therefore they don't merge anyway.

The reason I'm asking:

1. If they are NOT mergeable at all (separate domains) then we don't have
    a question (in COPS it would be different client types).

    PDP -> PEP: (Client-type-X)
        Role="Edge+Ethernet+TrustedInterface+Engineering" P1

    PDP -> PEP: (Client-type-Y)
        Role="Edge+Ethernet+TrustedInterface+Engineering" P2

2. If they are mergeable, then any PEP role combination can't get two
    of them since it is not supposed to know how to merge them. What
    needs to happen is that the PDP will merge both and send a COPS
    message for "Edge+Ethernet+TrustedInterface+Engineering" with merge(P1,P2).

Shai

At 11:22 AM 02/11/2000, Jon Sjoberg wrote:
>that supports "Edge+Ethernet" and P2 is destined for any PEP that supports 
>a TrustedInterface.
>
>>>your definition means that all the roles in a role combination 
>>>associated to a policy must be a proper subset of the roles on a PEP for 
>>>the policy to be loaded.
>>>
>>>So, for your example:
>>>
>>>"Edge+Ethernet+TrustedInterface+Engineering", then P1 would be 
>>>appropriate for that PEP.  Correct?
>>>