Subject: [Isis-wg] Call for WG Adoption for draft-you-isis-flowspec-extensions-04

From: <[email-masked]>
Date: Fri, 26 Feb 2016 13:43:17 -0500

Hi Folks,

The authors have requested the IS-IS WG adopt:

    https://datatracker.ietf.org/doc/draft-you-isis-flowspec-extensions/

as a working group document.

Please indicate your support or no-support for taking on this work.

Thanks,
Chris & Hannes.

---

From: Christian Hopps <[email-masked]>
Date: Fri, 26 Feb 2016 14:16:21 -0500

> On Feb 26, 2016, at 1:43 PM, <[email-masked]> <[email-masked]> wrote:
> 
> 
> Hi Folks,
> 

Speaking as a WG contributor and not as chair.

I am having some trouble accepting this solution is needed. The one use that has been given is a single operator who does not run BGP. The reason this is important is that BGP already provides a similar solution. But I believe the BGP solution exists not simply as a new way to configure routers, but b/c BGP enables inter-domain communication, and allows one AS to inform another AS about an attack. BGP is also better suited to carrying large amounts of data. Neither of these is true for IS-IS.

For the intra-domain only case the operator already has mechanisms in place for configuring it's own routers. I've asked this before but not really gotten any answer as to how this proposal doesn't simply represent using IS-IS as a router configuration protocol.

If this is the case why wouldn't the DDOS detecting device simply use an established configuration mechanism, perhaps netconf/yang, to add the required policy on the required routers?

Thanks,
Chris.

---

From: Marc Binderberger <[email-masked]>
Date: Sun, 28 Feb 2016 21:04:05 -0800

Hello Christian & IS-IS experts,

I agree with your comment. From my memory (the old ISP days ...):

(1) a big issue when DDoS attacks became the new "normal" was the coordinated 
fight. A private, operator-only mail list was used but response time was 
always an issue.

(2) thus signalling to your upstream or your peers was important. Obviously 
this is eBGP and RFC5575 is exactly solving this problem.

(3) inside your network you needed to distribute the information to the 
peering and uplink routers, potentially to your access routers too. You need 
routers that see the traffic without any label, i.e. the edge. Again RFC5575 
+ iBGP came handy.

(4) Tools like Arbor and Riverhead spoke (and speak) BGP.

(5) problem (3) can be - and initially was - solved with ACLs, either 
manually configured or with a configuration tool.

So (3) could be also addressed with an IGP like IS-IS. My personal opinion is 
that only (1) was the main driver for RFC5575 and to fiddle with a protocol. 
For problems like (3) the ISPs had been always inventive enough to use their 
OSS systems if nothing else was available. To be fair, in these days CLI was 
king, so enabling the network operators to send the attack to Null0 with a 
few BGP commands on one central router was a good thing (tm).

If we really want to use IS-IS as a transport for configuration then what 
about RFC6823 "Advertising Generic Information in IS-IS" ?  That exists 
already.

Regards, Marc

On Fri, 26 Feb 2016 14:16:21 -0500, Christian Hopps wrote:
> I am having some trouble accepting this solution is needed. The one use 
> that has been given is a single operator who does not run BGP. The reason 
> this is important is that BGP already provides a similar solution. But I 
> believe the BGP solution exists not simply as a new way to configure 
> routers, but b/c BGP enables inter-domain communication, and allows one AS 
> to inform another AS about an attack. BGP is also better suited to carrying 
> large amounts of data. Neither of these is true for IS-IS.
> 
> For the intra-domain only case the operator already has mechanisms in place 
> for configuring it's own routers. I've asked this before but not really 
> gotten any answer as to how this proposal doesn't simply represent using 
> IS-IS as a router configuration protocol.
> 
> If this is the case why wouldn't the DDOS detecting device simply use an 
> established configuration mechanism, perhaps netconf/yang, to add the 
> required policy on the required routers?
> 
> Thanks,
> Chris.
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: <[email-masked]>
Date: Mon, 29 Feb 2016 10:15:29 -0500

> few BGP commands on one central router was a good thing (tm).

And so here's the thing, we have IS-IS protocol modifications being
proposed here, OSPF has apparently accepted them, I just saw a new draft
to add similar changes to PCEP, will we also see the same changes for
RIP, Babel, EIGRP, ...?

I still don't understand why we don't define *1* yang model for flowspec,
and use the protocols already there to configure routers for configuring
routers.

> about RFC6823 "Advertising Generic Information in IS-IS" ?  That exists

I agree if moving forward with this I think we need to look at GENAPP as
well..

Firs though I'd like to hear more on why intra-domain flowspec (or the
equivalent) can't simply be defined using a yang model.

Thanks,
Chris.

---

From: Alia Atlas <[email-masked]>
Date: Mon, 29 Feb 2016 10:37:18 -0500

> and use the protocols already there to configure routers for configuring

I would strongly prefer to see one yang model for flowspec that can then be
used by multiple protocols.  A question is how to carry the results  in
each protocol?
Is it protocol-specific translation?  Is it extending a generic mechanism
to carry a self-describing binary?

On the yang model for flowspec, please do also talk to Sue Hares (cc'd).
This is
something that she has been looking at in reference to BGP and the
filter-specific
RIB model in I2RS.   One question that she raised is whether it is
desirable to have exactly the same functionality via a yang model as via
BGP flowspec.

I would strongly encourage discussion.  Part of this ties to what does it
mean to have a model-based protocol?  Can we enhance our existing
protocols?  Should we consider what a model-based protocol might look like
if done from scratch?

Thanks for raising the question about the elephant in the room!

Regards,
Alia

---

From: <[email-masked]>
Date: Mon, 29 Feb 2016 18:01:56 -0500

> to carry a self-describing binary?

And just to be clear I was suggesting that we use this yang model in
conjunction with existing netconf/restconf/etc protocols. These are
intra-domain routers after all. :)

This wouldn't replace the original BGP spec though as it is used as a
means for informing ones administrative neighbors of the need for
filtering.

> desirable to have exactly the same functionality via a yang model as via

Right, it seems logical to me that the model could be used by BGP as well.

> protocols?  Should we consider what a model-based protocol might look like

This is much broader idea and is pretty interesting in it's own right. :)

Thanks,
Chris.