Interface to the Routing System
charter-ietf-i2rs-02

Added milestone "Request publication of an Informational document providing an analysis of existing IETF and other protocols and encoding languages against the requirements", due February 2014, from current group milestones

[Ballot block]
Thanks Alia for solving my previous BLOCK point.

With the introduction of the charter version 1-3, I see a discrepancy in this bullet point:
o The ability to extract information about topology from the network. 
    Injection and creation of topology will not be considered as a work item.
    Such topology-related models will be based on a generic topology
    model to support multiple uses; the generic topology model should
    support writing of the topology to support non-I2RS uses.

The two sentences "injection and creation of topology will not be considered" and "the generic topology model should support writing of the topology" seem contradictory to me ". I guess I simply don't understand those.

Disclaimer: I read the latest I2RS mailing list messages (subject: [i2rs] simple rechartering underway) and, at this point in time, I don't know which part(s) of the different topology models should be read-only versus read-write.

[Ballot comment]

What does "Filter-based RIBs include a match of fields in IP header
plus other IP packet format fields" mean and how would it be
affected if the payload is ciphertext?

[Ballot block]
Thanks Alia, I welcome the I2RS charter changes.
However, I believe the charter needs one improvement.

The charter says:
The working group is chartered to work on the following items:
.
.
.
- Abstract information models and Yang Data Models consistent with
  the use cases.

Based on your guidance in the WG to skip the information models (http://www.ietf.org/mail-archive/web/i2rs/current/msg02320.html), I believe that this sentence is misleading.

OLD:

- Abstract information models and Yang Data Models consistent with
  the use cases.

NEW:

- Yang Data Models consistent with the use cases.

[Ballot comment]
- I've been confused for a while by the missing indentation of "Other use cases may be adopted by the working group only through rechartering.". I was thinking that the "The working group is chartered to work on the following items:" list stopped above that, and that the YANG models were not part of those.

-

    These models will be based on a generic topology model to support
    multiple uses. Injection and creation of topology will not be considered
    as a work item.

Not sure what "these models" refer to. And the weird identation doesn't help. These models refer to the previous bullet point, or to the list of bullet points?

[Ballot comment]
I can live with your resolution/explanation on point 1 and 2 below (from a previous BLOCK comment)

1.
Same old discussion about framework versus architecture.
You mentioned "high-level" in "High-level architecture and framework".
That's a step in the right direction.
Personally, I would change all instances of "High-level architecture and framework" to "High-level architecture"

2.
During the BoF, many use cases were discussed.
You asked: do we want to limit the use cases? Answer: yes
You asked: is 3 a reasonable number? Answer: yes
So how many do you have? It's not clear from the bullet points"

I'm concerned by the proliferation of use cases might be a problem.
The conclusions from the discussion with Adrian were:
- at this point in time, we don't know how many documents will be produced. So we can't specify it in the charter
- we will have to trust the chairs and AD to do the right thing in terms of document.

Not action is required on this point 2

[Ballot comment]
Thanks for addressing my DISCUSS.
While not perfect, I  live with your resolution/explanation on point 2 and 3

2.
Same old discussion about framework versus architecture.
So you included the two terms to make me happy? ;-)

The I2RS working group works to develop a framework and architecture that will
enable specific use cases, and lead to an understanding of the informational models
and requirements for encodings and protocols for the I2RS interfaces.

And now, we have a new term: architecture framework

Jul 2013 : Request publication of an Informational document defining the architecture framework

I don't understand how you could have this "architecture framework" before the use cases?
IMHO, the framework and architecture terms are not suitable. What you're after is the explanation of the required building blocks in the use case document(s).

And then, the framework or architecture (pick up the term you want) will explain:
to solve the use cases A, B, C, we need the building blocks D, E, F, with the interfaces G, H, I, the data model J, K, L, and the protocol M. However, that document will only exist in the next charter


3;
During the BoF, many use cases were discussed.
You asked: do we want to limit the use cases? Answer: yes
You asked: is 3 a reasonable number? Answer: yes
So how many do you have? It's not clear from the bullet points below " - Tightly scoped key use cases for operational use of I2RS as follows:"

[Ballot block]
Three points I want to discuss.

1.

I2RS facilitates real-time or event driven interaction with the routing system through a
collection of protocol-based control or management interfaces. These allow information,
policies, and operational parameters to be injected into and retrieved (as read or by
notification) from the routing system while retaining data consistency and coherency
across the routers and routing infrastructure, and among multiple interactions with the
routing system.

You mentioned multiple management interfaces. Good, because that's a fact, and will be a fact for many years to come.
Now, I was really after some text taking into account the data consistency and coherency across the different management interfaces. Maybe this is covered by the "among multiple interactions with the routing system", I read multiple times and I'm not sure: I would like to have clearly spell out. Basically, don't break any existing management interface.
The problem I want to solve is: a set of API that will be THE way to interact with the routing system without any consistency with the CLI, the show commands, a read MIB table, a YANG module.
Note:  I'm not dreaming, I actually had this specific discussion.

2.
Same old discussion about framework versus architecture.
So you included the two terms to make me happy? ;-)

The I2RS working group works to develop a framework and architecture that will
enable specific use cases, and lead to an understanding of the informational models
and requirements for encodings and protocols for the I2RS interfaces.

And now, we have a new term: architecture framework

Jul 2013 : Request publication of an Informational document defining the architecture framework

I don't understand how you could have this "architecture framework" before the use cases?
IMHO, the framework and architecture terms are not suitable. What you're after is the explanation of the required building blocks in the use case document(s).

And then, the framework or architecture (pick up the term you want) will explain:
to solve the use cases A, B, C, we need the building blocks D, E, F, with the interfaces G, H, I, the data model J, K, L, and the protocol M. However, that document will only exist in the next charter


3;
During the BoF, many use cases were discussed.
You asked: do we want to limit the use cases? Answer: yes
You asked: is 3 a reasonable number? Answer: yes
So how many do you have? It's not clear from the bullet points below " - Tightly scoped key use cases for operational use of I2RS as follows:"

[Ballot comment]
EDITORIAL:

"Collocated" and "with the with" in

While processes participating in the routing system are often colocated with the with
local forwarding elements, this isn't a necessary condition.

[Ballot comment]
I agree with Barry's comments about lack of definition about what's on the other side of the interface.  It makes it hard to assess whether people with different use cases (who will see the problem differently and favor different approaches and even different descriptions of what the problem is) will really get along after the WG starts, or if they're just playing nicely for now in order to get something SDNish chartered, and will fragment later.

That said, I trust Adrian completely, and don't feel the need to Block on it.

[Ballot comment]
My comment after discussion with Adrian:

> The subject of the interfaces is some lump of stuff that decides to poke the
> routing system. In the architecture (I-D) the subject end of the interface is
> called the I2RS Client and serves one or more "applications". We got a bit hung
> up about what constitutes an application: is it, for example, a P2P streaming
> application, or is it a tool that is responsible for shaping the network? In the
> end, the answer appeared to be "yes".

I would feel happier if some sense of that could be in the charter.  In general, when we propose creating an interface to X, we have some idea of who or what we want to be using that interface (the subject, as you say).  I understand the use cases document will go into that in much more detail, but I'd be happier if the charter said *something* about it.  I don't know whether you're talking about having a data center's operation & management system using the interface, having a web server that sits in a customer's office using the interface, or having a web browser that runs in an end-user's iPad using the interface.

If the answer really is, "Yes, all of those," then a few words in the charter should be possible, no?  "This interface is expected to be used by systems as diverse as a data center's operation/management system, a web server, and a peer-to-peer streaming application.  The working group will provide details of these and other applications as it develops its use cases."  Perhaps something like that could be added to the paragraph that begins "I2RS facilitates real-time or event driven interaction with the routing system"?

---

Especially because charters, including this one, don't have the sorts of citations and references that we have in RFCs, it would be helpful to expand "RIB" and "FIB" (and, for completeness, "BGP") on first use.  I know that routing people know those terms cold... but some of us don't (Wikipedia taught be that they're "Routing Information Base" and "Forwarding Information Base", so I'm now better informed).

[Ballot block]
I have two points I would like to discuss before sending this charter
out for IETF review.

1. I found this text somewhat confusing:

- Tightly scoped key use cases for operational use of I2RS. These use
  cases will include at least:

    o [list of use cases]

    Other use cases may be adopted by the working group only after
    milestones have been added to the charter page.

Exactly what sort of milestone(s) might be added to the charter page
to allow the WG to add more use cases?  How would this process differ
from the usual rechartering process; perhaps as an additional
constraint above and beyond the usual IESG/IETF review of a revised
charter?

2. While a minor point, it should be clarified: The third paragraph
refers to "informational models", while there is a work item for
"Abstract information models."  Is the difference in terminology
intentional?

[Ballot comment]

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.

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

- Shouldn't this recognise the SDN term/fad somehow so that
buzzword compliant people end up on the right mailing list?

- What's the relationship between this and the putative SDNRG
in the IRTF? Has that been discussed with e.g. Lars?

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

[Ballot block]
The second paragraph says this:

  I2RS facilitates real-time or event driven interaction with the
  routing system through a collection of control or management
  interfaces. These allow information, policies, and operational
  parameters to be injected into and retrieved (as read or by
  notification) from the routing system while retaining data
  consistency and coherency across the routers and routing
  infrastructure, and among multiple interactions with the routing
  system.

Nowhere that I can see does it give me any idea what the target of these interfaces is: what is it that you want having interaction with the routing system?  What is it that will inject information, policies, and operational parameters, that can't do so now?

[Ballot block]
The second paragraph says this:

  I2RS facilitates real-time or event driven interaction with the routing
  system through a collection of control or management interfaces. These
  allow information, policies, and operational parameters to be injected
  into and retrieved (as read or by notification) from the routing system
  while retaining data consistency and coherency across the routers and
  routing infrastructure, and among multiple interactions with the routing
  system.

Nowhere that I can see does it give me any idea what the target of these interfaces is: what is it that you want having interaction with the routing system?  What is it that will inject information, policies, and operational parameters, that can't do so now?

[Ballot comment]
Especially because charters, including this one, don't have the sorts of citations and references that we have in RFCs, it would be helpful to expand "RIB" and "FIB" (and, for completeness, "BGP") on first use.  I know that routing people know those terms cold... but some of us don't (Wikipedia taught be that they're "Routing Information Base" and "Forwarding Information Base", so I'm now better informed).