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

Hi Alia, Chris,

A Yang model based FlowSpec: https://tools.ietf.org/html/draft-wu-idr-flowspec-yang-cfg-02
Is this the draft that you may refer to? I think we still need to adapt it to IS-IS protocol if using Yang model?
The Yang model based FlowSpec does have some application scenarios, such as inject FlowSpec rules into specified routers by management system. In this document, we think FlowSpec is more like a n-tuple route. So we extend IS-IS.

Thanks,
Jianjie

发件人: Isis-wg [mailto:isis-wg-bounces@ietf.org] 代表 Alia Atlas
发送时间: 2016年2月29日 23:37
收件人: Christian Hopps; Sue Hares
抄送: Marc Binderberger; isis-wg@ietf.org
主题: Re: [Isis-wg] Call for WG Adoption for draft-you-isis-flowspec-extensions-04

On Mon, Feb 29, 2016 at 10:15 AM, <chopps@chopps.org<mailto:chopps@chopps.org>> wrote:

Marc Binderberger <marc@sniff.de<mailto:marc@sniff.de>> writes:

> 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).

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.

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

> 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.

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.

>
>
> Regards, Marc
>
>
>
>
> On Fri, 26 Feb 2016 14:16:21 -0500, Christian Hopps wrote:
>>
>>> On Feb 26, 2016, at 1:43 PM, <chopps@chopps.org<mailto:chopps@chopps.org>> <chopps@chopps.org<mailto:chopps@chopps.org>> wrote:
>>>
>>>
>>> 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.
>>
>> 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.
>>
>> _______________________________________________
>> Isis-wg mailing list
>> Isis-wg@ietf.org<mailto:Isis-wg@ietf.org>
>> https://www.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org<mailto:Isis-wg@ietf.org>
https://www.ietf.org/mailman/listinfo/isis-wg