Subject: [i2rs] multi-headed control

From: Alia Atlas <[email-masked]>
Date: Wed, 23 Jan 2013 17:04:39 -0500

I'd be interested in hearing others perspective on the use-cases requiring
multi-headed control and what you see this requirement as meaning.  This is
a rather
different requirement, in terms of embedding the policy-enforcement into
the
routing system, from what is currently done for CLI/NetConf/SNMP.  In those
cases,
the latest writing wins and installs its state.  For i2rs, an idea proposed
(in
http://tools.ietf.org/html/draft-atlas-irs-policy-framework) is that
different i2rs clients
are decided between based upon precedence.

Frequently, different services are "known" to not collide, based upon
human-assigned
policy - such as different prefixes for different traffic types, etc.

To get things started with a use-case, consider that there are two
different services
that are using i2rs.
    a) Special Traffic Flow Routing:  a service that installs policy-based
routing filters to
        route specific traffic on predetermined paths.
    b) DDoS Detection:  a service that detects traffic of interest and
installs policy-based
       routing filters to route the suspicious traffic to an analysis box.
In this case, the second service could have a higher precedence to override
the first service's
installed filters when necessary.

Any opinions?

Thanks,
Alia

---

From: Joe Marcus Clarke <[email-masked]>
Date: Wed, 23 Jan 2013 18:37:26 -0500

On 1/23/13 5:04 PM, Alia Atlas wrote:
> multi-headed control and what you see this requirement as meaning.  This
> is a rather
> routing system, from what is currently done for CLI/NetConf/SNMP.  In
> those cases,
> the latest writing wins and installs its state.  For i2rs, an idea
> proposed (in
>     a) Special Traffic Flow Routing:  a service that installs
> policy-based routing filters to
> In this case, the second service could have a higher precedence to
> override the first service's

More like a thought.  In the use case you describe, couldn't both
coexist?  Meaning you could simply have two PBR "actions," one that
routes the traffic and the other that copies the interesting traffic to
the DDoS sniffer.  So the precedence may be the same and both can
coexist.  Now, if the DDoS service finds a problem in the copied
traffic, it can install an overlapping policy that would preempt the
original.

As to the flow in the draft, if the new, higher-precedence service is
transient and the store-if-not-best bit is set, then the previous state
will be restored (if it has the next best precedence).  Shouldn't the
commissioner be notified again that its state is active again?

Joe

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: [email-masked]

----------------------------------------------------------------------------

---

From: Alia Atlas <[email-masked]>
Date: Wed, 23 Jan 2013 19:08:17 -0500

> traffic, it can install an overlapping policy that would preempt the

Exactly - both could exist unless the DDoS service finds a problem with
a flow being routed by the first service.

> commissioner be notified again that its state is active again?

Absolutely - I'll double-check to be sure that's in there when we revise
the draft.

Regards,
Alia

---

From: Joe Marcus Clarke <[email-masked]>
Date: Wed, 23 Jan 2013 19:16:49 -0500

On 1/23/13 7:08 PM, Alia Atlas wrote:
> 
> 
> On Wed, Jan 23, 2013 at 6:37 PM, Joe Marcus Clarke <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

That coexist wasn't clear (at least to me) in the draft or your
description here.  But maybe this wouldn't be considered overlap in the
precedence sense?

> Absolutely - I'll double-check to be sure that's in there when we revise

Thanks.

Joe

---

From: Alia Atlas <[email-masked]>
Date: Wed, 23 Jan 2013 19:19:57 -0500

On Wed, Jan 23, 2013 at 7:16 PM, Joe Marcus Clarke <[email-masked]>wrote:

> Yes, I wasn't considering it overlap - just like two routes in the RIB
aren't
overlapping if they're not the same prefix.

---

From: Joe Marcus Clarke <[email-masked]>
Date: Wed, 23 Jan 2013 19:26:27 -0500

> overlapping if they're not the same prefix. 

Got you.  So maybe the use case should make it clear that the DDoS
Service has already deemed a problem is seen (via some pre-programmed
copy op) and it is now overriding the pre-existing state with a higher
precedence state vs. simply inspecting traffic.

In general, I think there is value to this, especially in the
notification piece.  This may help management systems suspend polling
while a certain state is known not to exist.

Joe

---

From: Alia Atlas <[email-masked]>
Date: Wed, 23 Jan 2013 19:29:33 -0500

> precedence state vs. simply inspecting traffic.

Yes, the peril of not writing down assumptions.

> while a certain state is known not to exist.

Good to hear.
Providing good notifications seems critical to making good control loops
and having i2rs scale.

Alia