[GROW] Alia Atlas' No Objection on draft-ietf-grow-irr-routing-policy-considerations-05: (with COMMENT)

"Alia Atlas" <akatlas@gmail.com> Wed, 07 January 2015 23:07 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alia Atlas <akatlas@gmail.com>
To: The IESG <iesg@ietf.org>
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150107230725.28785.50829.idtracker@ietfa.amsl.com>
Date: Wed, 07 Jan 2015 15:07:25 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/grow/QAp_fUsyo54y1yxHZ1qMa1Br3tI
Cc: grow-chairs@tools.ietf.org, grow@ietf.org, draft-ietf-grow-irr-routing-policy-considerations.all@tools.ietf.org
Subject: [GROW] Alia Atlas' No Objection on draft-ietf-grow-irr-routing-policy-considerations-05: (with COMMENT)

Alia Atlas has entered the following ballot position for
draft-ietf-grow-irr-routing-policy-considerations-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-grow-irr-routing-policy-considerations/



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

[GROW] Alia Atlas' No Objection on draft-ietf-gro… Alia Atlas