Problem Statement for the Interface to the Routing System
draft-ietf-i2rs-problem-statement-11

[Ballot comment]
I basically agree with Alvaro's points. On top of that, a problem statement in 2016 when the charter was done in 2012 ... hmm ...
If (parts of) the content needs be published, it should be in the arch document. Figure 1 is architecture anyway, right?
And ... a problem statement with a normative reference to an architecture. Really?

[Ballot comment]
I'm not going to stand in the way of this document being published.

I am taking an abstain position as it is my preference that the informative rationale which guides the i2rs solution space should be in the Architecture document and what remains can exist as a living WG document for participants to reflect upon - that in itself need not be published as an RFC.

[Ballot comment]
I am sympathetic to the argument that this doesn't need to be published as an RFC. But I'm not going to block or abstain about that this late in the process.

I share Alvaro's other concern that there are a lot of assertions of "need" that do not seem to be supported by the text. They tend towards passive voice (e.g. "it is desirable", "is needed", "there is a need" ), which obscures who actually has these needs. I'd like to see more explanation of the "who" and the "why" for these needs.

The security considerations seem to say "security is important", and that authentication an authorization are required. I'd like to see more actual threat analysis.

[Ballot comment]
My position on these types of documents should be pretty clear at this point. The parts that do have archival value should be published as a part of a protocol specification or architecture document.

[Ballot comment]
I have sympathy with Álvaro's position, and thought about abstaining as well, but in the end I did find that the discussion in Sections 1 thru 4 has archival value, as guidance to people who are eventually reading the set of I2RS documents.  Sure, this could all be part of the architecture document, but if the working group's decision is to separate it out, I'm OK with that.

[Ballot comment]

- section 1: "different vendors' routing systems" seems like
it's assuming that there is only one vendor involved in each
box. I don't think that's consistent with what's behind i2rs so
re-wording there might be better.

- figure 1: I'm sure you'll fix the page break

- confidentiality for i2rs protocol: if I can watch i2rs traffic
I can probably infer what policies are being used and use that
to better attack networks. I think you could easily strengthen
the wording there and that'd be better.  If one has a way to
securely authenticate endpoints, then you can almost as easily
ensure confidentiality.

- general question: We know that govts target network admins.
What are we doing to make i2rs traffic less easily used as a
selector? (e.g. make sure it could work over Tor?)

- the secdir review [1] called out some nits you may want to
consider (if you did already thanks, I didn't check in detail)

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06342.html

[Ballot comment]
I had a hard time deciding on the value of this document as a standalone RFC.  I came to the conclusion that the valuable pieces (specifically Section 5) would serve a better purpose as part of the i2rs Architecture document (draft-ietf-i2rs-architecture).  If this document is to be published I won't stand in the way, I'm ABSTAINing instead.  I put more specific comments below.


The document contains a mixture of what I think are broad and vague requirements ("needs" and "key aspects") for an I2RS Protocol, along with a general picture of what an i2rs can/should be (which seems to step into the WG's charter in some places).

Maybe I can't see it, but the document expresses "needs" without explicit justification (e.g. "the need…real-time security threat responsiveness…more dynamically manage and program routing systems…support rapid control and analytics…automate even the simplest operations…support real-time, asynchronous interactions using efficient data models and encodings that are based on and extend those previously defined…learn topology, network analytics, and existing state from the network as well as to create or modify routing information and network paths…feedback loop…data-model driven interface to the routing system…precisely control routing and signaling state based upon policy or external measures…dynamically configure policies and parameter values for the various routing and signaling protocols based upon application-level policy decisions…detailed topological state that provides more information than the current functional status…") or details of what is expected, or a clear comparison to the current state (the Appendix is not referenced in the main text, nor is it comprehensive).

It is unclear to me whether all those "needs" are requirements, or how they are translated into them.  The last "need" mentioned above does present the current state of the art (BGP-LS) and it provides examples of missing information, but without indicating if anything is required.  Other requirement-like statements not associated with "needs" are equally unclear: "…providing the ability for an application to dynamically request that measurements be taken and data delivered is important."  I think everyone can agree that it is important, but is it a necessary characteristic of the I2RS protocol (or maybe something else?)?

Section 5 seems to spell out requirements for an I2RS Protocol, but the aspects listed/discussed I think fall short of providing strict guidance.


The term "I2RS" is sometimes used without a modifier (client, agent, protocol, etc.), not making it clear what the term is referring to.  Some of the missing modifiers seem obvious, but others seem to be potentially referring to the WG itself and trying to define what the scope or charter should be — that is obviously better served in the charter itself.  For example:

* "…the I2RS scope…"  Is that within the scope of the I2RS protocol, the WG, ??  One piece of text mentions "…outside the I2RS scope for standardization."  That makes me think that the answer is the i2rs WG, but then it makes me wonder why we need this document to clarify the WG's charter.

Then there are also explicit references to what the WG should do; again, better served by the charter itself.

* "The I2RS Working Group must select the suitable protocol(s) to carry messages between the I2RS Clients and I2RS Agent."  Even though it may be implicit, there's no explicit action in the i2rs WG charter to select a protocol, and of course no mention of clients/agents (as those are described in the Architecture).

* "The I2RS Working Group must identify or define a set of meaningful data-models for information in the routing system and in a topology database."  I think this is already part of the charter.

* "One set of data-models that I2RS should focus on is for interacting with the RIB layer…"  The charter mentions something similar.

* "At a minimum, within the I2RS scope…"  The scope of the WG, or are you talking about something else that hasn't been defined?

* "I2RS will define needed information and data models…"


Finally, it also worries me that other documents put too much stock in this one, relying on it to provide guidance in places where it falls short.  For example:  draft-ietf-i2rs-architecture says in Section 3. (Key Architectural Properties) that "some architecture properties such as performance and scaling are not described below because they are discussed in [I-D.ietf-i2rs-problem-statement]". 

* The word "performance" doesn't exist in draft-ietf-i2rs-problem-statement, but there are aspects (in Section 5) that resemble it: "should be able to handle a considerable number of operations per second", "within a sub-second time-scale, it should be possible to complete simple operations"…  I wouldn't call those Key Architectural Properties.

* There is some sparse treatment of scaling: "For example, for scaling, some exported data or events may be better sent directly from the forwarding plane…", or "Scalable, Filterable Information Access:  To extract information in a scalable fashion that is more easily used by applications, the ability to specify filtering constructs…is very valuable."  Again, not what I would call Key Architectural Properties.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-i2rs-problem-statement-09.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.  This is based on the 24 February 2012 form:

Document Shepherd: Qin Wu (bill.wu@huawei.com)
WG chairs:  Susan Hares and Jeff Haas
AD responsible: Deborah Brungard
RFC type: informational
Routing Reviewer: Eric Gray
OPS-DIR Reviewer: Sarah Banks
Gen-art Reviewer: Russ Housley
SEC-DIR Reviewer: Stephen Kent
Document write-up:

Technical Summary

  As modern networks grow in scale and complexity, the need for rapid
  and dynamic control increases.  With scale, the need to automate even
  the simplest operations is important, but even more critical is the
  ability to quickly interact with more complex operations such as
  policy-based controls.

  In order to enable network 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
  real-time, asynchronous interactions using data models and encodings
  that are efficient and potentially different from those available
  today.  Furthermore, the interface must be tailored to support a
  variety of use cases.

  This document expands upon these statements of requirements to
  provide a detailed problem statement for an Interface to the Routing
  System (I2RS).

Working Group Summary

Consensus was complete in the working group after 2 year of review

Document Quality:

Document is ready to ship, but there is one unused reference RFC4292 which might link to Appendix A,
suggest to add reference to where it was referenced in this document.

----
(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Review was an editorial, nits, and technical. 

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

Due to the new direction of this work, early reviews were requested.
Reviews for OPS-DIR, RTR-DIR, GEN-ART, and SEC-DIR have been done.
There are no concerns from document Shepherd.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Due Security and operational complexity of the I2RS dynamic state approach,
early reviews were requested from OPS-DIR, RTR-DIR, SEC-DIR, and GEN-ART.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Call for IPR done on list.  Awaiting David Ward and Thomas Nadeau's response.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

IPR has been requested (even if questionable on problem statements):
Still awaiting Thomas Nadeau and David Ward's response.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

This document has strong consensus in the I2RS WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. 

No conflict on the document or discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

no nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review criteria as a problem statement.

(13) Have all references within this document been identified as
either normative or informative?

Yes, there is only informative references. 3 are RFCs and 2 are WG I-Ds.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

no downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No change to other RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

Not applicable since this is a problem statement.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No additional IANA registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

no XML, BNF, MIB definitions in draft.

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: i2rs@ietf.org, bill.wu@huawei.com, draft-ietf-i2rs-problem-statement@ietf.org, db3546@att.com, i2rs-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Interface to the Routing System Problem Statement) to Informational RFC


The IESG has received a request from the Interface to the Routing System
WG (i2rs) to consider the following document:
- 'Interface to the Routing System Problem Statement'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-02-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Traditionally, routing systems have implemented routing and signaling
  (e.g.  MPLS) to control traffic forwarding in a network.  Route
  computation has been controlled by relatively static policies that
  define link cost, route cost, or import and export routing policies.
  With the advent of highly dynamic data center networking, on-demand
  WAN services, dynamic policy-driven traffic steering and service
  chaining, the need for real-time security threat responsiveness via
  traffic control, and a paradigm of separating policy-based decision-
  making from the router itself, the need has emerged to more
  dynamically manage and program routing systems in order to control
  routing information and traffic paths and to extract network topology
  information, traffic statistics, and other network analytics from
  routing systems.

  This document proposes meeting this need via an Interface to the
  Routing System (I2RS).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.  This is based on the 24 February 2012 form:

Document Shepherd: Qin Wu (bill.wu@huawei.com)
WG chairs:  Susan Hares and Jeff Haas
AD responsible: Alia Atlas
RFC type: informational
Routing Reviewer: Eric Gray
OPS-DIR Reviewer: (TBD, requested early review)
Gen-art Reviewer: Russ Housley
Document write-up:

Technical Summary

  As modern networks grow in scale and complexity, the need for rapid
  and dynamic control increases.  With scale, the need to automate even
  the simplest operations is important, but even more critical is the
  ability to quickly interact with more complex operations such as
  policy-based controls.

  In order to enable network 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
  real-time, asynchronous interactions using data models and encodings
  that are efficient and potentially different from those available
  today.  Furthermore, the interface must be tailored to support a
  variety of use cases.

  This document expands upon these statements of requirements to
  provide a detailed problem statement for an Interface to the Routing
  System (I2RS).

Working Group Summary

Consensus was complete in the working group after 2 year of review

Document Quality:

Document is ready to ship, but have 1 policy question for authors and
8 editorial questions:

Policy question:
1.Section 2 said:
"The second critical aspects are meaningful data-models for information
  in the routing system and in a topology database ."

What about policy information in the policy database?
Doesn’t information in the routing system contain information in the topology database?
Suggested resolution: delete "topology" ‘in a topology database’

Editorial issues:

1. Text after the figure 1 in the Section 2 said:
" A critical aspect  of I2RS is defining a suitable protocol or
  protocols to carry messages between the I2RS Clients and the I2RS
  Agent, and defining the data-models for use with those I2RS
  protocol(s)."

"The second critical aspect are meaningful data-models for information
  in the routing system and in a topology database."

The word "aspect" is overused and "aspect" in the above two sentences represent different meaning,suggest the first aspect into "task" or reword the two paragraphs.

2. Section 2 said:

"The second critical aspect are meaningful data-models for information
  in the routing system and in a topology database ."

Suggested solution:  either s/aspect/aspects or reword the sentence.

3.Section 2 said:
"The data models should translate into a concise
  transfer syntax that is straightforward for applications to use
  (e.g., a Web Services design paradigm)."

By reading this sentence, it is not clear what is translated?
data model or information from the routing system?

4.Section 3, first paragraph said:
" In addition, by having I2RS focus
  initially on interfaces to the RIB layer (e.g.  RIB, LIB, multicast
  RIB, policy-based routing), the ability to use routing indirection
  allows flexibility and functionality that can't be as easily obtained
  at the forwarding layer."

I think here we should highlight the downside of using existing mechanism.
suggest to break the sentences at:  " the ability to use routing indirection allows flexibility and functionality that can't be as easily obtained at the forwarding layer."

into two sentences, e.g.,

“ the ability to use routing indirection allows flexibility and functionality. However this flexibility and functionality can't be as easily obtained
  at the forwarding layer.

or rephrase it as follows:
"Flexibility and functionality provided by using routing indirection can't be as easily obtained at the forwarding layer "

5.Section 4, second paragraph said:
" Detailed topological state that provides more information than the current
  functional status is needed by applications; only the active paths or
  links are known versus those potentially available  (e.g.
  administratively down) or unknown (e.g. to peers or customers) to the
  routing topology. "

Text quoted here is not a clear sentence, think about how to reword it.

6 Section 8: Security consideration section
Would it be better to add something to say this document is problem statement draft
Security considerations are not addressed in this problem statement only document. Instead it will be addressed in some protocol documents in the future.

7.  - In Section 9
Reference  [I-D.gredler-idr-ls-distribution] should be updated to  [I-D.ietf-idr-ls-distribution]
----
(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Review was an editorial, nits, and technical.  The

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

Reviews pending for OPS-DIR, RTR-DIR, GEN-ART, and SEC-DIR.
Due to the new direction of this work, early reviews were requested.
Excepted return time 12/16/2014.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Due Security and operational complexity of the I2RS dynamic state approach,
early reviews were requested from OPS-DIR, RTR-DIR, SEC-DIR, and GEN-ART.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

Section 2 said
  "The second critical aspects are meaningful data-models for information
  in the routing system and in a topology database ."

Question: What about policy information in the policy database?
Doesn’t information in the routing system contain information in the topology database?

Resolution: Suggest to delete ‘in a topology database’

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Call for IPR done on list.  Awaiting David Ward and Thomas Nadeau's response.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

IPR has been requested (even if questionable on problem statements):
Awaiting Thomas Nadeau and David Ward's response.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

This document has strong consensus in the I2RS WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. 

No conflict on the document or discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

no nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review criteria as a problem statement.

(13) Have all references within this document been identified as
either normative or informative?

Yes, there is only informative references.  All are RFCs except for draft-gredler-idr-ls-distribution (see comment #9 above).  This will be updated prior to sending in this review.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

no downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No change to other RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

Not applicable since this is a problem statement.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No additional IANA registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

no XML, BNF, MIB definitions in draft.