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

> On 1/23/13 7:08 PM, Alia Atlas wrote:
> >
> >
> > On Wed, Jan 23, 2013 at 6:37 PM, Joe Marcus Clarke <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> >     On 1/23/13 5:04 PM, Alia Atlas wrote:
> >     > 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?
> >
> >     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.
> >
> >
> > Exactly - both could exist unless the DDoS service finds a problem with
> > a flow being routed by the first service.
>
> 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?
>
> Yes, I wasn't considering it overlap - just like two routes in the RIB
aren't
overlapping if they're not the same prefix.

> >
> >
> >     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?
> >
> >
> > Absolutely - I'll double-check to be sure that's in there when we revise
> > the draft.
>
> Thanks.
>
> 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 protected]
>
>
> ----------------------------------------------------------------------------
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to