Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration
draft-ietf-grow-irr-routing-policy-considerations-06

[Ballot comment]
[My comments are similar to Alia’s review of –05.]

It is somewhat hard to pinpoint the expected outputs promised in the Introduction, where is says that the "purpose of this document is to catalog past issues...  Additionally, it provides a discussion regarding which of these issues still pose problems in practice, and which are no longer obstacles…”  Section 3 seems to provide a roadmap of the document pointing out the pieces covered:  "First, accuracy and integrity of data contained within the IRR.  Second, the Resource Policy Specification Language (RPSL) used to represent various types of data in the IRR.  Third, operation of the IRR infrastructure, i.e.: synchronization of resources from one IRR to other IRRs.  Finally, the methods related to extraction of policy from the IRR and the input plus activation of that policy within routers.”    While that is ok, there’s no clear correlation with the TOC.

The contents of the document don’t have to strictly be reflected in the TOC, but it would be nice to at least call out which sections cover the points listed above.  According to my reading, that would be 4 (for #1), 5.1 (for #3) and 5.2, 6 and 7 (for #4).  It is not clear to me that independent issues related to RPSL (and not related to #1) are covered..any are intermingled in Section 4.

Going back to the purpose of the document.  Section 8 (Summary) says that "many of the problems that have traditionally stifled IRR deployment have, themselves, become historical”.  But in my reading the only issue that seems to not be an obstacle anymore is the graceful application of policy in BGP (Section 6 and 7).  If the intent was to highlight others as non-issues then that should be made clearer.


Nits:
Section 4. (Accuracy and Integrity of Data Contained within the IRR) s/section/sections
Section 5.1. (Replication of Resources Among IRRs)  s/has a several weaknesses/has several weaknesses
Section 5.2. (Updating Routing Policies from Updated IRR Resources)  s/An ISP's customers/An ISP's customer

[Ballot comment]
Thank you for putting the effort into this draft!

The latest revision is improved, and addresses 98% of my comments when I was wearing a routing area directorate reviewer hat. Mostly I'm pleased to see a sentence in there which highlights that the RPKI doesn't carry routing policy information. I think there is a very real undertone in this document that shouldn't be avoided in that the RPKI takes steps to routing security, but misses a mark on policy integrity.

I still don't buy the ideal that 10gig circuits are perceived as the norm - but happy to let that go as a future ideal.. mores law and all :)

This document is one of the better outcomes of documenting in the IETF what was (is) and why wrt routing.

[Ballot comment]
I see you have some high-level considerations that could encompass the various security properties that would be expected, but would prefer to see them spelled out a bit.  For instance, in the first paragraph of the security considerations section:
"operators may want to be
  circumspect about ingesting contents from external parties"

Wouldn't you want to see integrity protection so that the operators would have some level of assurance that the source is who they think it is and that the data has not been tampered.  This might apply to the described examples where FTP is used to share information.  Authentication would be helpful here too.

Then, if automation increases, you would also want confidentiality (session encryption for privacy and security reasons).  C

This this is a summary of current state, this is just a comment.  But I would think these properties are used in the current state - at least integrity protection and authentication.  (Security's CIA principle)

Thanks.

[Ballot comment]
I support Adrian's Discuss on the need to have Terry's review comments addressed.

I also found this draft a bit hard to read and parse - though not to the extent of pulling
out specific examples, but please do think about Barry's comments as well.

Although the abstract and intro claim that the draft will provide a discussion of the
existing or remaining concerns, I would STRONGLY (not quite DISCUSS but...) like
them to be pulled out more clearly.  Without this, the draft seems to be more retrospective
and rambling than clearly articulating what was a problem, what changed, and what still
remained as a problem.

For instance, from reading the draft, I would say that:
  a) Getting fresh IRR data is still a problem.  Pull mechanisms use long intervals based
      upon historic problems (see Sec. ...) and push mechanisms are not fully described.
  b) RPKI provides a solution only for verifying route origination but this is not sufficient
      for verifying IRR data because such data also includes asnum, etc.
  c) Stale data in IRRs:  incentives don't exist for removing stale data and overriding the
      existing data requires work and has the risk of black-holing if the data wasn't really stale
  d) Propogation delay across different ISPs affect how rapidly changes can occur.
  e) Configuration based on the new IRR data is less operator-intensive because of the ability
      to use NetConf to deliver the updates, but a lack of vendor-agnostic models still makes
      such updates complicated.
  f) Router capabilities are rarely a problem anymore.  (Incremental updates of prefix-lists,
      more static memory, BGP extensions to push new config in without traffic-impacting side-effects).

I'm sure I've missed some and maybe gotten a few wrong- but I'd really like to see some actual
takeaways.  This currently leaves me feeling like I had a good dinner conversation chatting about
how bad the old times were but without any action items or guidance for the future to improve.

[Ballot comment]
I support Adrian's Discuss on the need to have Terry's review comments addressed.

I also found this draft a bit hard to read and parse - though not to the extent of pulling
out specific examples, but please do think about Barry's comments as well.

Although the abstract and intro claim that the draft will provide a discussion of the
existing or remaining concerns, I would STRONGLY (not quite DISCUSS but...) like
them to be pulled out more clearly.  Without this, the draft seems to be more retrospective
and rambling than clearly articulating what was a problem, what changed, and what still
remained as a problem.

For instance, from reading the draft, I would say that:
  a) Getting fresh IRR data is still a problem.  Pull mechanisms use long intervals based
      upon historic problems (see Sec. ...) and push mechanisms are not fully described.
  b) RPKI provides a solution only for verifying route origination but this is not sufficient
      for verifying IRR data because such data also includes asnum, etc.
  c) Stale data in IRRs:  incentives don't exist for removing stale data and overriding the
      existing data requires work and has the risk of black-holing if the data wasn't really stale
  d) Propogation delay across different ISPs affect how rapidly changes can occur.
  e) Configuration based on the new IRR data is less operator-intensive because of the ability
      to use NetConf to deliver the updates, but a lack of vendor-agnostic models still makes
      such updates complicated.
  f) Router capabilities are rarely a problem anymore.  (Incremental updates of prefix-lists,
      more static memory, BGP extensions to push new config in without traffic-impacting side-effects).

I'm sure I've missed some and maybe gotten a few wrong- but I'd really like to see some actual
take-aways.  This currentlyleaves me feeling like I had a good dinner conversation chatting about
how bad the old times were but without any action items or guidance for the future to improve.

[Ballot comment]
I think this is a good document to publish.  Thanks for the effort.

I agree with Adrian that Terry's review comments need to be addressed.

[Ballot comment]


Thanks for this. I learned from reading it and following
some links etc. I think other readers will be similarly
educated.

- I agree with Adrian's request that the routing review
be discussed. In particular, wrt the relationship
between this work and the RPKI - it'd be good that that
be (checked as having been) documented correctly. No
disrespect to the authors here, but the RPKI vs. IRR
stuff here is not that crisply described - most likely
(I'm guessing) because that relationship is just in
reality vague. But if I'm recalling correctly some of
the very capable authors here aren't the biggest fans of
the RPKI so it'd be good for them and this document that
their description of RPKI be challenged now a little bit
rather than that be done later (if that has not already
happened, which may well be the case).

- 5.1, I'd be interested in why RFC2725 is now seen as
then having been a barrier to deployment and whether or
not that is still considered to be the case. Put another
way - was the problem the security requirements or the
design provided in 2725? (Note, I'm not asking for any
change, just wondering.)

- section 6 has a "[REF?]" that's presumably an undone
TBD

[Ballot comment]
I find some of the writing throughout the document to be a bit hard to get through -- not to the extent that I think it's a serious problem, but enough so that I'd say this is making the reader work a bit too hard.  Some examples:

  While these resources
  are generally allocated by hierarchical authorities, a general
  mechanism for formally verifying (such as through cryptographic
  mechanisms) when parties have been allocated resource remains an open
  challenge.  We generally define such a system a Resource
  Certification System, and we note that some candidate examples of how
  such a general system might be implemented and deployed exist[.]

The structure of both of these sentences makes understanding them require a bit of rewinding and re-parsing, at least for me.  Phrases such as "have been allocated resource" seem odd ("allocated resources" or "allocated a resource" would seem better).  Phrases such as "some examples exist" are straightforward, but get harder when a long modifying phrase is stuck in before "exist", as here.  This is an example; there are other such bits in the document.

In the end, it's probably fine, though I think it'd be a good idea to alert the RFC Editor to watch for complicated sentences whose structure makes then a bit difficult to read smoothly.  Below I suggest a few specific sentences that I hope the authors will re-do themselves, before it goes to the RFC Editor.

-- Section 4.1 --

  One of the largest weaknesses often cited with the IRR system is that
  the data contained within the IRRs is out of date or lacks integrity.
  This is largely attributable to the fact that existing IRR mechanisms
  do not provide ways for a relying party to (cryptographically) verify
  the validity of an IRR object.  That is, there has never existed a
  resource certification infrastructure that enables a resource holder
  to authorize a particular autonomous system to originate network
  layer reachability advertisements for a given IPv4 or IPv6 prefix.

Two questions here:

1. The last sentence is written as a clarification of the one before it ("that is..."), but seems to veer.  Would it perhaps be better to say, "...that enables a resource holder to verifiably authorize...", or, "...that enables a resource holder to provide verifiable authorization that a particular autonomous system may originate..." ?

2. This clearly explains the "lacks integrity" piece, but adding cryptographic verifiability will not fix out-of-date information, will it?  Isn't there also an issue of keeping the information current in the first place, which is not mentioned here?

-- Section 4.5 --

  Only now is an
  experimental test bed that reports to provide this function

I think "purports" is the word you're looking for here.

-- Section 5.2 --

  An ISP's customers may not adequately plan for pre-planned
  maintenance or, more likely, need to rapidly begin announcing a new
  IP prefix as a result of, for example, an emergency turn-up of the
  ISP customer's new downstream customer.

I'm having trouble making sense of this sentence.  The subject seems to change throughout the sentence, starting as "an ISP's customers", and shifting to the ISP later.  Can you please re-word this, perhaps splitting it into two sentences?  (It'd also be nice if you'd use "might" to refer to something that might happen, and save "may" for referring to something that's *allowed* to happen.)

  It is likely that the length of time at which IRRs mirror
  changes will have to be dramatically reduced with a corresponding
  reduction in time at the ISPs that, in turn, need to evaluate whether
  changes in a set of IRR resources need to get reflected in updated
  router policies that will get pushed out to ASBR's, connected to
  peering circuits, on their network.

I get this one, in the end, but it's also in need of splitting into two, please.

-- Section 6 --

  Ultimately, either of the two scenarios above further lengthen the
  effective time it would take for changes in IRR resources to take
  affect within BGP in the network.

That should be "take effect", not "take affect".  And I think the combination of "effective time" and "take effect" can be confusing, so maybe try some rewording?

[Ballot discuss]
I'd like to see some discussion of the points raised by Terry Manderson in his Routing Directorate review during the IETF last call period (circulated on the Grow list at http://www.ietf.org/mail-archive/web/grow/current/msg03015.html).

By preference this discussion should be between the authors, WG, and reviewer. But I'd be happy to step in and own the discussions if that will help.

from kk

This document catalogs past issues influencing the efficacy of
Internet Routing Registries (IRR) for inter-domain routing policy
specification and application in the global routing system over the
past two decades.  It also discusses, which of these issues are still
problematic and which aren't.

I feel that this document is generally ready.

Non-technical question for authors:

From Summary section: "Because of this state increase, the potential
to model all policies for all ASes in all routers may still remain
illusive"

While English is not my first language, I'm not sure if you meant
'elusive' instead of 'illusive'. While the word could certainly be
used here, I'm not sure if you're implying whether the potential is
hard to get to (elusive), or merely an illusion that isn't or won't be
real (illusive).

Regards,
KK

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-grow-irr-routing-policy-considerations-05, which is currently in Last Call, and has the following comments:

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

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

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

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IRR & Routing Policy Configuration Considerations) to Informational RFC


The IESG has received a request from the Global Routing Operations WG
(grow) to consider the following document:
- 'IRR & Routing Policy Configuration Considerations'
  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 2014-12-01. 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


  The purpose of this document is to catalog past issues influencing
  the efficacy of Internet Routing Registries (IRR) for inter-domain
  routing policy specification and application in the global routing
  system over the past two decades.  Additionally, it provides a
  discussion regarding which of these issues are still problematic in
  practice, and which are simply artifacts that are no longer
  applicable but continue to stifle inter-provider policy-based
  filtering adoption and IRR utility to this day.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-grow-irr-routing-policy-considerations/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-grow-irr-routing-policy-considerations/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.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Informational

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

The purpose of this document is to catalog past issues influencing
  the efficacy of Internet Routing Registries (IRR) for inter-domain
  routing policy specification and application in the global routing
  system over the past two decades.  Additionally, it provides a
  discussion regarding which of these issues are still problematic in
  practice, and which are simply artifacts that are no longer
  applicable but continue to stifle inter-provider policy-based
  filtering adoption and IRR utility to this day.

Working Group Summary

There was no discussion that was difficult or hairy.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

The document does not discuss a protoocol, it discusses considerations for use and abuse of IRR routing policy creation.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Shepherd: Chris Morrow
AD: Joel Jaeggli
             
(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.

I reviewed the document during it's draft cycle and at WGLC. I believe it to be ready for publication at this time.

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

I don't have any concerns about the depth or breadth of reviews of this document.

(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.

No

(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 at this time.

(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.

Yes

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

N/A

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

The wg consensus was solid for this document.

(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. (It should be in a
separate email because this questionnaire is publicly available.)

no threats of appeal.

(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.

The data of the document is 63 days in the past, this seems ok though.

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

N/A

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

Yes

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

No.

(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

(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


(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).

N/A

(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.

N/A

(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.

N/A