[Dots] 答复: Re Fwd: New Version Notification for draft-nishizuka-dots-inter-domain-mechanism-00.txt

["Xialiang (Frank)" <[e-mail]>]

Hi Roman,
Please see my response inline:

发件人: Roman D. Danyliw [mailto:[e-mail]]
发送时间: 2016年3月11日 6:18
收件人: Xialiang (Frank)
抄送: [e-mail]; kaname nishizuka
主题: RE: [Dots] Re Fwd: New Version Notification for draft-nishizuka-dots-inter-domain-mechanism-00.txt


Hello Frank!



(Chair hat off …)

> From: Dots [mailto:[e-mail]] On Behalf Of Xialiang (Frank)

> 发件人: Dots [mailto:[e-mail]] 代表 Roman D. Danyliw

> 主题: Re: [Dots] Fwd: New Version Notification for draft-nishizuka-dots-

> inter-domain-mechanism-00.txt



[snip]

> ** Page 3 – 5, Section 2,  In laying out these problems, what new

> requirements for draft-ietf-dots-requirements-00 are suggested?  Do you

> see this problems as only applicable to the use cases/architectures described

> in Section 3?

> [Frank]: Good question. In this part, we try to list all the problems related

> with the ddos protection coordination. Some of them are general (i.e.,

> Bootstrapping, coordination, provision, etc), some are more specific with

> inter-domain condition (i.e., near source protection, billing, etc). So, these

> problems are not only applicable for Section 3 and more broad than it. If

> necessary, it should be synchronized with the DOTS use cases/requirements

> drafts.



I think that synchronization would help.  From the problem statement in Section 2, articulating the requirements that they suggest would help clarify the unique needs of these use cases (if any).

[Frank]: Ok, we will do it in next version.



[snip]

> ** Page 6, Section 3, “flow analyzer” definition.  This term is defined as part

> of ecosystem, but it is not used again in the document.  Is it needed?

> [Frank]: I think it’s not yet decided whether DOTS should cover the work

> related to the interface/protocol of flow analyzer. But in reality, it is widely

> used for the ddos attack detection.



To clarify, do you mean that the WG hasn't discussed the data channel sufficiently, or that there is an additional element (flow analyzer?) in the DOTS architecture (per the requirements draft) that needs to be described (beyond a client, server, relay and mitigator).

[Frank]: I mean both. I hope we can include this part of work in DOTS WG.



> ** Page 6 – 8, Section 3.1,  In the distributed architecture, can you clarify why

> the DOTS server and DOTS client need to be coupled in a controller?  Is the

> controller a new part of the DOTS architecture that needs to accounted for in

> the protocol?  Is the introduction of the term “controller” to get around the

> fact that the current definition of a DOTS server is “network element … [that

> communicates] the DOTS client’s request to a mitigator”.  Effectively, clients

> send requests to servers/proxies.  Servers only send requests to mitigators;

> not other servers?

> [Frank]: From our viewpoint, “The ISP controller should support the functions

> of DOTS server and DOTS client at the same time in order to participate in the

> system of inter-domain DDoS protection service.  In other words, as the

> representative for an ISP's DDoS protective service, the ISP controller

> manages and provides DDoS mitigation service to its customer in one hand,

> but may require helps from other ISPs under some situation especially when

> the attack volume exceeds its capacity or the attack is from other ISPs. ”,

> especially for the inter-domain ddos protection scenario.



Thanks for the clarification. In figure 1, why are there multiple DOTS clients/servers in ISP 1?  Could there be two servers one client; or two clients and one server; one client and one server?  I'm trying to understand what DOTS considerations exists between what appears to be a tight 1:1 coupling of server/client in the orchestrator.  Like noted above with the flow analyzer, in the view of the draft, is the orchestrator is an additional element of the DOTS architecture?

[Frank]: Good question. In general, one ISP can have multiple DOTS systems to be responsible for its multiple domains respectively. It can relieve the traffic pressure to one DOTS system in the ISP network, and provide the optimized near-source mitigation in certain level. I also think different deployment ways as you mentioned above can work in various occasions. 1:1 coupling of server/client in the orchestrator is now a simple model but is enough for most occasions. I think the orchestrator should be an additional element for the DOTS architecture.



Roman