Subject: Comments on draft-shaikh-rtgwg-policy-model

From: <[email-masked]>
Date: Mon, 20 Jul 2015 11:35:14 +0000

Hi,

As pointed this morning during the WG session :

-          We need to clarify (asap if possible) the boundary between this policy model and what should be defined in protocol models to extend the policy. In the current version, it looks like a mix of having part of IGP defined in the generic policy framework and so expecting some other extensions in IGP models. For BGP, all is within BGP. My proposal would be to let all the protocol extensions to be in protocol models, this includes :

o   Protocol specific matching

o   Protocol specific actions

o   Install-protocol identity for that protocol => so need to remove the existing ones for ISIS, OSPF, BGP in the current version.

-          Regarding tags, as pointed today, I would like to have "tag" to be a generic local identifier rather than pointing only to IS-IS and OSPF. Any route within a RIB may have a local tag (this local tag can be learned from the routing protocol or set by configuration or policy). So setting a tag does not refer to any igp-action.

-          Also regarding the "igp-action" container, I'm not in favor of having separate containers for igp-actions, bgp-actions and generic-actions. Two possibilities :

o   Each protocol creates a container (e.g. isis-actions, ospf-actions ...) which augments the action container. Isis-actions and ospf-actions may be different (for example in setting route-type or metric type ...)

o   Just having the "actions" container and put all the actions here whatever the applicable protocol.

o   Similar approach to be taken for protocol specific conditions

-          I would be in favor in adding routing table matching condition and a way to select also a destination routing table. E.g. , I use an import policy to force a routing protocol to insert routes in a specific routing table rather than the default one. Or I want to authorize routes from multiple routing tables to be exported to a particular protocol.

Best Regards,

[Orange logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE
Orange Expert Future Networks
phone: +33 2 23 28 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
mobile: +33 6 37 86 97 52 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
[email-masked]<mailto:[email-masked]>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 20 Jul 2015 13:46:49 +0200

> On Jul 20, 2015, at 1:35 PM, <[email-masked]> <[email-masked]> wrote:
> 
> -          Regarding tags, as pointed today, I would like to have “tag” to be a generic local identifier rather than pointing only to IS-IS and OSPF. Any route within a RIB may have a local tag (this local tag can be learned from the routing protocol or set by configuration or policy). So setting a tag does not refer to any igp-action.

I believe we do wish to keep this field used for IGP route tagging since that's a protocol component.  
(Fascinating issue, while researching ISIS implementations I found that the protocol permits 64bit tagging, but didn't find anyone that implemented them.)

I do realize that there is also a need to do general route mark-up so that policy engines can operate off of that.  I know that for certain route types, the "tag" field might be able to be used for this purpose; e.g it has no semantics in a given BGP implementation unless the route is redistributed in the IGP.  (And I'm not even sure that field survives export, I'd have to check the code.)

Perhaps more appropriate would be to have a new mark-up field, name TBD, to cover this purpose.  It could then be implemented as appropriate for a given route type and vendor implementation?

-- Jeff

---

From: <[email-masked]>
Date: Mon, 20 Jul 2015 12:21:09 +0000

Hi Jeff,

Inline comments

From: Jeffrey Haas [mailto:[email-masked]]
Sent: Monday, July 20, 2015 13:47
To: LITKOWSKI Stephane SCE/IBNF
Cc: [email-masked]
Subject: Re: Comments on draft-shaikh-rtgwg-policy-model

On Jul 20, 2015, at 1:35 PM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

I believe we do wish to keep this field used for IGP route tagging since that's a protocol component.
[SLI] Do we really need to differentiate from a policy point of view ? from an import policy perspective, matching a tag, means learning the tag value available in the protocol (if available) and when the route ins inserted into RIB the tag value is copied from the protocol value if not overrided by import policy action; from an export policy perspective (talking about export from rib to protocol), matching a tag means matching the tag value in the RIB (which may come from protocol or not),  setting a tag means fill the protocol field if available. From a RIB point of view, the tag associated with the route is protocol agnostic, even if the protocol does not support tags in encoding you may associate a local tag for policy processing.

Having two types of tags is also possible : protocol-tag and local-tag but I see more complexity and do not see more flexibility : but maybe there is some use case that I do not see.

(Fascinating issue, while researching ISIS implementations I found that the protocol permits 64bit tagging, but didn't find anyone that implemented them.)
[SLI] ☺ we have it in IS-IS yang model , tag64 if I remember correctly.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 20 Jul 2015 14:44:06 +0200

Stephane,

> On Jul 20, 2015, at 2:21 PM, <[email-masked]> <[email-masked]> wrote:
> 

The messy detail with this attribute is that while it's useful as a generic policy element, in specific protocol context it needs to have differing constraints.  OSPF has one set of constraints, RIP a slightly different one (zero is reserved), and ISIS has different sizes with some option for one or two tags plus the 64-bit tag previously discussed.

This set of context specific constraints probably removes some level of the flexibility that you'd want for it to be a generic marker - unless you can live within the least common denominator.

-- Jeff

---

From: <[email-masked]>
Date: Mon, 20 Jul 2015 13:58:39 +0000

Right, each protocol has its own constraint, but do you think creating an additional generic marker will solve those constraints ? We would expect to be able to have the generic marker to protocol tag and also two protocol tags with different constraints to interact between each other (I mean for example, learning a RIP tag and copying it to ISIS or OSPF).

From: Jeffrey Haas [mailto:[email-masked]]
Sent: Monday, July 20, 2015 14:44
To: LITKOWSKI Stephane SCE/IBNF
Cc: [email-masked]
Subject: Re: Comments on draft-shaikh-rtgwg-policy-model

Stephane,

On Jul 20, 2015, at 2:21 PM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 20 Jul 2015 16:05:04 +0200

> On Jul 20, 2015, at 3:58 PM, [email-masked] wrote:
> 

My thought is that by not using an element that has protocol semantics, we can free the user from worrying about them when they don't care about whether the route will or will not get redistributed into a protocol that might use it.  This is mostly to deal with your "local" property noted earlier.

-- Jeff

---

From: <[email-masked]>
Date: Mon, 20 Jul 2015 14:29:58 +0000

Inline

From: Jeffrey Haas [mailto:[email-masked]]
Sent: Monday, July 20, 2015 16:05
To: LITKOWSKI Stephane SCE/IBNF
Cc: [email-masked]
Subject: Re: Comments on draft-shaikh-rtgwg-policy-model

On Jul 20, 2015, at 3:58 PM, [email-masked]<mailto:[email-masked]> wrote:

[SLI] Agree, that's why I was pushing "tag" to be protocol agnostic and having only this tag and then let implementations to manage the translation to protocol tag when necessary.

-- Jeff

---

From: Rob Shakir <[email-masked]>
Date: Tue, 21 Jul 2015 15:30:28 +0100

Folks,

There’s some ambiguity in the discussion here, from my perspective:

Option A: single ‘tag’ type which can represent a protocol tag, or some ‘colour’ attribute.
Option B: multiple ‘tag’ types, a generic ‘colour’ and then per-protocol tags.

Right now, oc-policy uses option A. I can see arguments for either - but Stephane I was not clear from your view which of these you prefer - can you clarify for me please?

Thanks,
r.

On 20 July 2015 at 15:30:56, [email-masked] ([email-masked](mailto:[email-masked])) wrote:

> > On Jul 20, 2015, at 3:58 PM, [email-masked](mailto:[email-masked]) wrote:
> >  
> >  
> >  
> >  
> >  
> >  
> [SLI] Agree, that’s why I was pushing “tag” to be protocol agnostic and having only this tag and then let implementations to manage the translation to protocol tag when necessary.
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> -- Jeff
>  
>  
>  
>  
>  
>  
>  
> _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.  
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: <[email-masked]>
Date: Tue, 21 Jul 2015 15:52:50 +0000

Sure ...

In the current version of the doc, option A is : single ‘tag’ type which can represent a protocol tag (it's only related to IGP tags in the draft)

So I would be in favor of option C :) (slight variation of option A) which is really single ‘tag’ type which can represent a protocol tag, or some purely local ‘colour’ attribute.

-----Original Message-----
From: Rob Shakir [mailto:[email-masked]] 
Sent: Tuesday, July 21, 2015 16:30
To: LITKOWSKI Stephane SCE/IBNF; Jeffrey Haas
Cc: [email-masked]
Subject: RE: Comments on draft-shaikh-rtgwg-policy-model

Folks,

Thanks,
r.

---

From: Rob Shakir <[email-masked]>
Date: Tue, 21 Jul 2015 19:30:23 +0100

Hi Stephane,

Thanks for the clarification.

The challenge that we might have here is that there are cases where I may want to match/set the ‘colour’ as well as an IGP tag. For instance, if I want to mark something in the RIB to say that it should be propagated to neighbour sets Amber, Blue and Cyan - which each have their own colour value - but these values also have an associated IGP tag. Given that we can have both, it seems to me that we should prefer to look at something that is like Option B.

IMHO, the intent of the tag we have today [0] is really to be the ‘generic colour’ type of tag, since we did not model IGP policies yet I don’t think that we examined this issue in too much detail — although Jeff and others have pointed it out before, and we marked it as something we did need to look at!

Best,
r.

[0]: I’d recommend using the latest version of the YANG, which is  at https://github.com/YangModels/yang/tree/master/experimental/openconfig/policy

On 21 July 2015 at 16:53:15, [email-masked] ([email-masked]) wrote:

Sure ...  

-----Original Message-----  
From: Rob Shakir [mailto:[email-masked]]  
Sent: Tuesday, July 21, 2015 16:30  
To: LITKOWSKI Stephane SCE/IBNF; Jeffrey Haas  
Cc: [email-masked]  
Subject: RE: Comments on draft-shaikh-rtgwg-policy-model  

Folks,  

Thanks,  
r.

---

From: <[email-masked]>
Date: Wed, 22 Jul 2015 07:32:07 +0000

Hi Rob,

Agree with the case you presented, IMO, we may provide some guidance to implementation on the behavior to use when a local-tag is translated to a protocol-tag and translation is not possible due to protocol-tag constraint (for example “do not copy tag”).

From: Rob Shakir [mailto:[email-masked]]
Sent: Tuesday, July 21, 2015 20:30
To: LITKOWSKI Stephane SCE/IBNF; Jeffrey Haas
Cc: [email-masked]
Subject: RE: Comments on draft-shaikh-rtgwg-policy-model

Hi Stephane,

Best,
r.

On 21 July 2015 at 16:53:15, [email-masked]<mailto:[email-masked]> ([email-masked]<mailto:[email-masked]>) wrote:
Sure ...

-----Original Message-----
From: Rob Shakir [mailto:[email-masked]]
Sent: Tuesday, July 21, 2015 16:30
To: LITKOWSKI Stephane SCE/IBNF; Jeffrey Haas
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Comments on draft-shaikh-rtgwg-policy-model

Folks,

Thanks,
r.

On 20 July 2015 at 15:30:56, [email-masked]<mailto:[email-masked]> ([email-masked](mailto:[email-masked]))<mailto:[email-masked](mailto:[email-masked]))> wrote:

> Cc: [email-masked]<mailto:[email-masked]>
> > On Jul 20, 2015, at 3:58 PM, [email-masked](mailto:[email-masked])<mailto:[email-masked](mailto:[email-masked])> wrote:
> >
> >
> >
> >
> >
> >
> [email-masked]<mailto:[email-masked]>

---

From: Jon Mitchell <[email-masked]>
Date: Wed, 22 Jul 2015 03:39:31 -0400

> Agree with the case you presented, IMO, we may provide some guidance to implementation on the behavior to use when a local-tag is translated to a protocol-tag and translation is not possible due to…

I'd also point out that some implementations (even from the same
vendor!) have different behavior on whether to default copy up from
lcoal tag to protocol tag even when it is possible when redistribution
is configured.

-Jon

---

From: Rob Shakir <[email-masked]>
Date: Wed, 22 Jul 2015 09:18:06 +0100

The way that we have tried to approach these things with the OpenConfig initiated models is “what is the way that we use this feature” - and then try and design the way that the model works around this.

To me, it seems like I want to be able to explicitly control whether something that I am using as a local route marker (‘colour’) is propagated to any of my neighbours via a particular routing protocol - otherwise, it takes on other semantics that I might not intend it to do.

In the local-routing [0] module, we use ‘tag’ as a protocol-agnostic way to mark particular routes — and then when these locally generated routes are imported into other protocols, then attributes for those protocols can be set (e.g., BGP community etc.). It strikes me that we should have something similar in each protocol export policy that says match on the local ‘tag’/‘colour’ and set protocol-tag value X (or even a switch that says ‘propagate tag’ assuming that the colour type can be mapped to the protocol tag type). 

I’d really like to separate local ‘tag’/‘colour’ from ‘tag’ within any particular protocol.

Cheers,
r.

[0]: https://github.com/YangModels/yang/blob/master/experimental/openconfig/local-routing/local-routing.yang 

On 22 July 2015 at 08:39:55, Jon Mitchell ([email-masked]) wrote:

-Jon

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 22 Jul 2015 10:37:39 +0200

> On Jul 22, 2015, at 10:18 AM, Rob Shakir <[email-masked]> wrote:
> 

This is the substance of my suggested separate attribute rather than using "tag".  I'm quite aware of operators using tag for this purpose, but it has impact in protocol and redistribution depending on implementation.  

There is some advantage to simply picking a similar attribute in an abstract fashion and letting a vendor choose where it goes to in the implementation.

-- Jeff

---

From: <[email-masked]>
Date: Wed, 22 Jul 2015 12:43:03 +0000

I have no issue to have two tags as long as I can have dynamic copy of the one the other (copying local tag to protocol tag, or reverse, or a protocol tag between two different protocols …).

From: Rob Shakir [mailto:[email-masked]]
Sent: Wednesday, July 22, 2015 10:18
To: Jon Mitchell; LITKOWSKI Stephane SCE/IBNF
Cc: Jeffrey Haas; [email-masked]
Subject: Re: Comments on draft-shaikh-rtgwg-policy-model

Cheers,
r.

On 22 July 2015 at 08:39:55, Jon Mitchell ([email-masked]<mailto:[email-masked]>) wrote:

-Jon

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 26 Jul 2015 17:49:28 +0000

I’ve read all the E-mails in this thread and I think I agree with Stephane in that a route has one or more tags that are advertised within the protocols and are installed into the appropriate RIB. This is the most straight forward and useful application of tags.

I think having two types of tags for routes (local and IGP) will only add complexity and confusion.

Thanks,
Acee

From: rtgwg <[email-masked]<mailto:[email-masked]>> on behalf of Stephane Litkowski <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 22, 2015 at 2:43 PM
To: Rob Shakir <[email-masked]<mailto:[email-masked]>>, Jon Mitchell <[email-masked]<mailto:[email-masked]>>
Cc: Routing WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: Comments on draft-shaikh-rtgwg-policy-model

Cc: Jeffrey Haas; [email-masked]<mailto:[email-masked]>

Cheers,
r.

-Jon

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 27 Jul 2015 11:50:51 -0400

Acee,

> I think having two types of tags for routes (local and IGP) will only add complexity and confusion.

What do you think the model should say about redistribution of tags that are
out of range of the protocol in question?

What do you think, if anything, the model should have in the way of
constraints on this scenario?  Note that this is a leading question since we
don't get constraints on operational state until yang 1.1, if I recall
correctly.

-- Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 27 Jul 2015 17:46:48 +0000

Hi Jeff, 

> On Jul 27, 2015, at 11:50 AM, Jeffrey Haas <[email-masked]> wrote:
> 
> Acee,
> 

This is one reason why I believe the redistribution or import policies should be within the protocol themselves rather than external to the protocol. There is less to constrain if you have per protocol redistribution. Now, dependent on where we end up with factoring the common policy, there may still be stuff that needs to be checked. 

> don't get constraints on operational state until yang 1.1, if I recall

I’m not sure why we need constraints for operational data in this case. 

Thanks,
Acee

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 27 Jul 2015 15:12:03 -0400

Acee,

On Mon, Jul 27, 2015 at 05:46:48PM +0000, Acee Lindem (acee) wrote:
> This is one reason why I believe the redistribution or import policies
> should be within the protocol themselves rather than external to the
> protocol. There is less to constrain if you have per protocol
> redistribution. Now, dependent on where we end up with factoring the
> common policy, there may still be stuff that needs to be checked. 

That's really where we're heading with regard to this model.  While BGP is
obviously the first target, this is also the beginnings of a fundamental
policy algebra that multiple protocols may share.

I'm not saying that this isn't a "solved" issue in any number of
implementations.  I suspect results go from truncation all the way through
blocking the redistribution depending on the protocol.  Or perhaps even the
protocol does the wrong thing and crashes the Internet. :-)

But since we're effectively working on this as an IETF common component for
yang, I do believe we need to figure out what it does.

> I’m not sure why we need constraints for operational data in this case. 

By example:
For a static route, if tag is set and tag is 0 and 0 is illegal for RIP, the 
operational state of the static route is tag=0.  It is possible for a
redistribution policy for static into RIP to detect an invalid operational
constraint and "do something".

Static is perhaps a weak example since one could model this against the
configuration state, but once you move the example into a learned protocol
such as OSPF, we're back to this problem.

-- Jeff

---

From: Antoni Przygienda <[email-masked]>
Date: Mon, 27 Jul 2015 20:20:51 +0000

> obviously the first target, this is also the beginnings of a fundamental policy
> algebra that multiple protocols may share.
> 
[Tony saiz:] 

Interesting, we're bringing RPSL back ? And if so, providers are willing to share their policies finally ;-)  ? 

-- Tony

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 27 Jul 2015 16:35:23 -0400

On Mon, Jul 27, 2015 at 08:20:51PM +0000, Antoni Przygienda wrote:
> Interesting, we're bringing RPSL back ?

I missed the RPSL wars, but got to heavily soak in their results for a few
years. :-)

I think we'll see this go a lot further than RPSL since we're really dealing
with internal router configuration rather than trying to express such policy
in an inter-provider scenario.

>  And if so, providers are willing to share their policies finally ;-)  ? 

Not a chance.

What's mildly amusing is that some discussions about route-leak mitigation
(see discussion in grow and (s)idr) may have implications about "disclosing
enough" to do the job.  I owe those WGs a writeup of the idea.

-- Jeff

---

From: Antoni Przygienda <[email-masked]>
Date: Mon, 27 Jul 2015 21:04:34 +0000

I was just poking to have fun since I fought (and implemented) the RPSL wars to be mildly blown off by ISPs telling me [what, sharing our access lists ? you claim you can anonymize them fully ? nice but nah, sorry ] ? ;-) 

Answers expected, I'll look it up once some first version is available. More than RPSL ? intriguing. RPSL was a closed algebra with closure so I really want to see how  this baby is  even better ;-)  Linear programming ? 

thanks 

--- tony
 
An idealist believes that the short run doesn't count. A cynic believes the long run doesn't matter. A realist believes that what is done or left undone in the short run determines the long run. ~~~ Sidney J. Harris 

> Sent: Monday, July 27, 2015 1:35 PM
> To: Antoni Przygienda
> Cc: Acee Lindem (acee); [email-masked]
> > > That's really where we're heading with regard to this model.  While
> > > BGP is obviously the first target, this is also the beginnings of a
> > > fundamental policy algebra that multiple protocols may share.
> > >
> > [Tony saiz:]
> >
> I missed the RPSL wars, but got to heavily soak in their results for a few years. :-)
> 
> I think we'll see this go a lot further than RPSL since we're really dealing with
> internal router configuration rather than trying to express such policy in an inter-
> provider scenario.
> 
> What's mildly amusing is that some discussions about route-leak mitigation (see
> discussion in grow and (s)idr) may have implications about "disclosing enough"
> to do the job.  I owe those WGs a writeup of the idea.
> 
> -- Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 27 Jul 2015 21:24:47 +0000

Hey Jeff,

On Jul 27, 2015, at 3:12 PM, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:

Acee,

By example:

I think we should have one full-range uint32 tag-type that is supported by all protocols, installed in the RIBs, and included in the RIB operational state. I like the current definition, only it would be good if we could limit the hex-string to the range 0x0 - 0xffffffff since, as you also pointed out, only 32 bits tags have been implemented. Note that I noted this as well and did not include 64-bit tags in https://www.ietf.org/id/draft-acee-ospf-admin-tags-02.txt.

typedef tag-type {
       type union {
         type uint32;
         type yang:hex-string;
       }
       description "type for expressing route tags on a local system,
       including IS-IS and OSPF; may be expressed as either decimal or
       hexidecimal integer";
       reference
         "RFC 2178 OSPF Version 2
         RFC 5130 A Policy Control Mechanism in IS-IS Using
         Administrative Tags";
     }

There still is a consideration though - how many tags a particular vendor supports in a tag-set? Right now, I believe it is 1 or 2 ;^)

Thanks,
Acee

-- Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 27 Jul 2015 21:29:58 +0000

Hey Tony, 

> On Jul 27, 2015, at 4:20 PM, Antoni Przygienda <[email-masked]> wrote:
> 

The model has “call” but is not fully procedural. More like a route-map with nesting. 

> And if so, providers are willing to share their policies finally ;-)  ? 

This is not required - they only need to make sure their polices map to the model. 

Thanks,
Acee

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 27 Jul 2015 17:32:23 -0400

On Mon, Jul 27, 2015 at 09:04:34PM +0000, Antoni Przygienda wrote:
> Answers expected, I'll look it up once some first version is available.
> More than RPSL ? intriguing. RPSL was a closed algebra with closure so I
> really want to see how  this baby is  even better ;-)  Linear programming? 

Better is arguable.  More flexible and inside-a-box complete, perhaps.

>From a functional standpoint, the stuff has branch logic.  All else could
collapse out to the same arguments of yore, but this simple detail makes
things a lot more palatable to policy consumers and writers.

-- Jeff