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

Hi Marc, Chris, and Les,

Thank you all for your comments. 
We'll think about using FlowSpec YANG model in this case for a next step. 

Best Regards,
Jianjie

> -----邮件原件-----
> 发件人: Marc Binderberger [mailto:marc@sniff.de]
> 发送时间: 2016年3月7日 7:57
> 收件人: Youjianjie
> 抄送: Christian Hopps; isis-wg@ietf.org
> 主题: Re: 答复: [Isis-wg] Call for WG Adoption for
> draft-you-isis-flowspec-extensions-04
> 
> Hello Jianjie,
> 
> sorry for my delayed reply.
> 
> > I'm not sure RFC6823 could be appropriate for supporting dissemination
> > of FlowSpec rules.
> 
> I guess your reply is based on another comment you made ...
> 
> > "[...] we think FlowSpec is more like a n-tuple route."
> 
> ... and I would disagree with the n-tuple _route_. What flowspec distributes is
> a policy/filter, aiming to interrupt by dropping, rate-limiting, quarantining etc..
> 
> 
> > Can it be regarded as an example of application of RFC6823?
> 
> well, everything can be treated as application :-) if it is not needed by IS-IS to
> do it's main task and IS-IS internal data is not needed for the new task. In this
> case I would say yes, we can. What you want from IS-IS is transporting
> flowspec data through the domain.
> 
> 
> > If it could, then we need to define FlowSpec under the framework of
> RFC6823?
> 
> yes, you would need to request an application ID and would move the
> (sub-)TLVs you define in your draft into the TLV 251 framework.
> 
> Separating the IS-IS main functionality from transporting flow-spec
> information will have an impact on section 4.1.2. "Validation Procedure" in
> your draft. This procedure seems a 1:1 copy from the original BGP work. For
> IS-IS I don't see the point. And draft-ietf-idr-bgp-flowspec-oid actually modifies
> the rules for BGP to accept any originator in your administrative domain,
> which translated into IS-IS means "no check".
> 
> I would propose to drop this validation check in your draft.
> 
> 
> 
> Saying all this: I still think this is best done by a controller programming
> flow-spec into network elements; YANG models help here. This is outside of
> what routing protocols should be involved in.
> 
> 
> Regards, Marc
> 
> 
> 
> 
> 
> On Thu, 3 Mar 2016 02:48:11 +0000, Youjianjie wrote:
> > Hi Marc,
> >
> >> -----邮件原件-----
> >> 发件人: Isis-wg [mailto:isis-wg-bounces@ietf.org] 代表 Marc Binderberger
> >> 发送时间: 2016年2月29日 13:04
> >> 收件人: Christian Hopps
> >> 抄送: isis-wg@ietf.org
> >> 主题: Re: [Isis-wg] Call for WG Adoption for
> >> draft-you-isis-flowspec-extensions-04
> >>
> >> 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.
> >
> > I'm not sure RFC6823 could be appropriate for supporting dissemination of
> > FlowSpec rules. If it could, then we need to define FlowSpec under the
> > framework of RFC6823? Can it be regarded as an example of application of
> > RFC6823?
> >
> > Thanks,
> > Jianjie
> >
> >> 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>
> <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
> >>> https://www.ietf.org/mailman/listinfo/isis-wg
> >>
> >> _______________________________________________
> >> Isis-wg mailing list
> >> Isis-wg@ietf.org
> >> https://www.ietf.org/mailman/listinfo/isis-wg