Hi Carlos,

Thanks for the review and comments.  Responses in-line now that I'm home
and recovered from IETF.

Alia

On Sun, Jul 28, 2013 at 5:07 PM, Carlos Pignataro (cpignata) <
[email protected]> wrote:

> I support I2RS adoption of this document.
>
> This is a very nice document. I also wanted to provide a small set of
> review feedback comments (marked with "CMP"):
>
>            Interface to the Routing System Problem Statement
>                  draft-atlas-i2rs-problem-statement-01
>
> Abstract
>
>    In order to enable applications to have access to and control over
>    information in the Internet's routing system, we need a publicly
>    documented interface specification.  The interface needs to support
>
> CMP: Where it says "In order to enable applications", I wonder if we need
> to further qualify "network applications", to differentiate a custom
> routing app versus a db query. Note this comment applies also to the
> Introduction.
>

[Alia] Sure.


>    This document expands upon these statements of requirements to
>    provide a detailed problem statement for an Interface to the Internet
>    Routing System (I2RS).
>
> CMP: The acronym does not expand, "Interface to the Internet Routing
> System" seems to be "I2IRS" (extra Internet).
>

[Alia] Ok - I've taken out Internet.  Really, the interface applies
regardless.


> 2.  I2RS Model and Problem Area for The IETF
>
>                    Figure 1: I2RS model and Problem Area
>
> CMP: Figure 1 shows a single interface from an I2RS Client into an I2RS
> Agent. For model completeness, would it make sense to add another "<-->"
> (i.e., within scope) interface from the leftmost I2RS client into a
> different I2RS Agent? Even something like "<-----> To another I2RS Agent".
>

[Alia] Sure

3.  Standard Data-Models of Routing State for Installation
>
>    There is a need to be able to precisely control routing and signaling
>    state based upon policy or external measures.  This can range from
>
> and
>
>    In addition to interfaces to the RIB layer, there is a need to
>    configure the various routing and signaling protocols with differing
>    dynamic state based upon application-level policy decisions.  The
>
> CMP: It is not clear to me what "signaling" specifically refers to here.
>
> 3.  Standard Data-Models of Routing State for Installation
>
>    This means that, to usefully model
>    next-hops, the data model employed needs to handle next-hop
>    indirection (e.g. a prefix X is routed like prefix Y) as well as
>    different types of tunneling and encapsulation.
>
> CMP: a nit: "indirection", or "indirection and recursion"?
>
[Alia] sure

5.  Desired Aspects of a Protocol for I2RS
>
>    Multiple Simultaneous Asynchronous Operations:   A single application
>       should be able to send multiple operations to I2RS without being
>       required to wait for each to complete before sending the next.
>
> CMP: "via I2RS" instead of "to I2RS".
>

[Alia] sure

   Duplex:   Communications can be established by either the I2RS client
>       (i.e.: that resides within the application or is used by it to
>       communicate with the I2RS server), or the I2RS server.  Similarly,
>
> CMP: Should "I2RS agent" be used instead of "I2RS Server", for
> nomenclature consistency?
>

[Alia] Yes - good catch

>
> 5.  Desired Aspects of a Protocol for I2RS
>
> CMP: I think there are some aspects potentially missing. Specifically:
> CMP: 1. Conflict resolution or Conflict notification (2 Apps fighting for
> the same route)
> CMP: 2. Security (and specifically integrity)
> CMP: 3. Accounting.
>

[Alia] I think that (1) belongs in the architecture.  I agree that it is
important - but I feel that the problem-statement part is covered in the
Multi-Headed Control.
(2) is mostly covered in "Secure Control".  I did add "Such communications
must also have its integrity protected." since we hadn't mentioned
integrity but just authentication and authorization.
For (3), I'm not sure what aspects specifically apply to I2RS...  We have
authentication and authorization and, in the architecture, tracking of
state written.  What knobs or functionality are you looking for in
accounting?

Alia


> Thanks!
>
> -- Carlos.
>
>
> On Jul 24, 2013, at 11:53 PM, Alia Atlas <[email protected]> wrote:
>
> > Please review draft-atlas-i2rs-problem-statement-01 and comment on
> whether it should be adopted by I2RS.  Detailed technical conversation is
> also most welcome.
> >
> > Authors: Are you aware of any IPR that applies to
> draft-atlas-i2rs-problem-statement-01? Is so, has this IPR been disclosed
> in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for
> more details).
> >
> > This WG call for adoption will complete on August 12.
> >
> > Thanks,
> > Alia
> > _______________________________________________
> > i2rs mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/i2rs
>
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to