Stephen wrote > None of these are blocking for me, but I'd appreciate answers, > especially to the first. > > - I'm confused about the single ADMD thing - how does that > square with mitigating DoS? I'd have thought that many DDoS > mitigations might require co-operation between at least two > domains. A solution that fits this charter might be too > limited to be useful.
Agree, but let's not boil the ocean on day one. Just because a solution is only applicable in a single domain does not preclude extending it in the future. In fact, the control structure in I2RS is an application talking to 1 or more I2RS clients talking to one or more I2RS agents. The limitation in the charter basically precludes the I2RS client being in a different admin domain from the I2RS agent - going there would make for interesting trust and security relationships. Architecturally, there is nothing to preclude an application talking to I2RS clients in different admin domains, or an application talking to another application in another domain - however, these interactions do not form part of the work of the WG and so do not need to be in scope. > - I'm confused about why this WG is needed - is there a real > prospect of not picking openflow for this or are we talking > about some other API? Many questions arise: 1. What makes you so sure that anyone would pick OpenFlow? 2. Don't you consider NetFlow (which is how I read your question first time!), ForCES, or any other IETF protocol might not be a real candidate? 3. If OpenFlow was picked where would the work to model IP routers be best carried out (this is NOT the forwarding plane that is being modelled)? 4. If IETF protocol X was picked would the work be in this WG or an existing WG? 5. Where do we do the work on requirements and (abstract) information models? > - Shouldn't this recognise the SDN term/fad somehow so that > buzzword compliant people end up on the right mailing list? I've never heard the term "SDN" before. Could you clearly and concisely explain it to me? Actually, I think that the term "SDN" is so last year. Quite possibly, I2RS fits into part of the SDN problem space. Quite possibly, calling it SDN just derails everyone into thinking this is a shiny thing and not something that people really want to build and deploy in IP networks. > - What's the relationship between this and the putative SDNRG > in the IRTF? Has that been discussed with e.g. Lars? AFAIK, IETF WGs produce protocol specs for stuff people want to build and deploy soon. The valuable work done by the IRTF RGs investigates longer-term research-based issues. The usual suspects (e.g. Dave Meyer who has been chairing the SDNRG work) are on the I2RS list and are (I think) supportive. Lars, of course, sees all proposals for new WGs and can comment. > - A nit: "A routing system is all or part of a routing > network. A part of a routing network may be a single router > or a collection of routers" reads oddly to me. Are you > including non-routing hosts or not? What about switches? > What about the wires? Oh, gods, how we thrashed on this text! And we're not done yet. Yes, I believe we are excluding non-routing hosts as they have no routing components that we can influence. We are definitely excluding switches - they do not route. AFAIK wires cannot be configured (I might be wrong on this, I don't keep up-to-date with my Physics). Anyway, they don't play a part in the routing system, although the interfaces that may be on the end of wires or groups of wires do play a part. Others may like to comment. Cheers, Adrian _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
