Subject: [GROW] WGLC: draft-ietf-grow-irr-routing-policy-considerations

From: Christopher Morrow <[email-masked]>
Date: Mon, 12 May 2014 09:59:46 -0400

Working Group Folks:

The authors of draft-ietf-grow-irr-routing-policy-considerations would
like to bring the draft to WGLC, this is that LC. Please have a read
through:

  <https://datatracker.ietf.org/doc/draft-ietf-grow-irr-routing-policy-considerations/?include_text=1>

Who's abstract is:
  "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."

and raise questions/comments/suggestions/eggs on this list.

I expect this WGLC to last for the normal 2wk period ending:
  26-May-2014

-chris
grow-co-chair

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 12 May 2014 16:04:08 -0400

in the vein of suggestions, in section 5.1:
  "Furthermore, the NRTM protocol does not
   employ any security mechanisms.  The NRTM protocol relies on a pull
   mechanism and is generally is configured with a poll interval of 5 to
   10 minutes."

the second sentence doesn't parse all that well, extra 'is' perhaps?
also, no validation/security on the protocol seems sketchy, but I
guess that's part of the point of pointing it out.

I'm also not sure this matters:
  "Cache locality results in reduced
   bandwidth utilization for each round trip."

and it's not actually the case, the same bandwidth is used, just not
across AS boundaries (perhaps)... It's probably the case though that
the lookups are 'faster' as RTT is generally lower (probably) for the
cached copy lookups and server capacity-planning can be managed such
that there aren't contention issues on the cached copies.  (the same
comment about bandwidth appears further up in section 5.1, it's also
mostly irrelevant there as well, I think)

-chris

---

From: "George, Wes" <[email-masked]>
Date: Mon, 12 May 2014 16:54:53 -0400

I think the authors need to look at this
http://iepg.org/2014-03-02-ietf89/ietf89_iepg_jmauch.pdf and make some
updates to section 7. Doesn’t really seem like all of those problems are
historical.

It would be extremely helpful to have a summary or conclusion section that
makes it clearer which problems are still in need of a solution,
especially if the goal is to have IETF provide all or part of that
solution. I think that it is useful to categorize the problems into things
that are essentially old, solved problems and therefore used as FUD
objections vs things that are still known issues, but a clearer call to
action to resolve the still outstanding issues would make this draft much
stronger.

Draft also needs text in the security considerations section.

Lastly, why is this a standards-track document and not informational?

Thanks,

Wes

On 5/12/14, 9:59 AM, "Christopher Morrow" <[email-masked]>
wrote:

>_______________________________________________
>GROW mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/grow

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Danny McPherson <[email-masked]>
Date: Mon, 12 May 2014 16:07:48 -0600

> updates to section 7. Doesn’t really seem like all of those problems 

Indeed!

> action to resolve the still outstanding issues would make this draft 

OK, I'll circle with Eric and others on this and see if we can expand 
on this a bit.  If you've got specific things in mind please send text.

> Lastly, why is this a standards-track document and not informational?

Good point, it should indeed be informational.

Thanks for the review Wes,

-danny

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 13 May 2014 14:22:56 -0400

>   <https://datatracker.ietf.org/doc/draft-ietf-grow-irr-routing-policy-considerations/?include_text=1>

Wes covered most of the points I would raise - missing security
considerations in particular.  Basically, if you filter using IRR and the
IRR has issues (perhaps maliciously induced), you'll have routing issues.
The entire first part of the document does very well at outlining where the
issues are and some of the paths for fixing them.

The snippy bit of me wants there to be comments that a lot of the
operational issues identified (e.g. "soft reconfig") are mostly one major
vendor's issue, but I think it's enough to simply say "these were the sins
of the past and no need to name names".  (There is plenty of sin to go
around.)

In general, once the security considerations are addressed, this makes a
fine Informational document and I think it's ready to go.  What's
frustrating is that the state of the art hasn't changed much since I was
doing IRR related work in 2000.

-- Jeff

---

From: Danny McPherson <[email-masked]>
Date: Wed, 14 May 2014 08:05:51 -0400

> issues are and some of the paths for fixing them.

That makes sense to me, there are external dependencies and if you use them you better have some sort of buffer or things could be really ugly.  Are there other things you’d like to see included here?

> doing IRR related work in 2000.

Or me in 94/95, for that matter — wohoo, two decades!  Except that the routing system was more secure then, perhaps, because it was less densely interconnected and fewer meatheads had keyboard access to BGP speaking routers..

-danny

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 14 May 2014 08:23:41 -0400

On Wed, May 14, 2014 at 08:05:51AM -0400, Danny McPherson wrote:
> That makes sense to me, there are external dependencies and if you use them you better have some sort of buffer or things could be really ugly.  Are there other things you?d like to see included here?

I suspect volumes could be written there, but the answer to most of them is
RPKI and some form of bgpsec.  It's good enough for this particular
document.

-- Jeff

---

From: Danny McPherson <[email-masked]>
Date: Wed, 14 May 2014 08:41:19 -0400

> RPKI and some form of bgpsec.  It's good enough for this particular

Actually, I don’t think the answer is BGPSEC at all if you’re concerned about routing policy issues and external systems or actors influencing routing. I think you actually want to go in precisely the other direction, but I don’t believe that discussion needs to occur in this document.

-danny