Subject: [GROW] New RPSL via attributes in the autnum Class

From: Job Snijders <[email-masked]>
Date: Wed, 9 Oct 2013 14:45:23 -0700

Dear GROW Group,

Recently I submitted the following internet draft to the IETF for review
and standardization:

    http://tools.ietf.org/html/draft-snijders-rpsl-via-02

The document defines two attributes in the aut-num Class which can be
used in RPSL policy specifications to publish desired routing policy
regarding non-adjacent networks.

I am struggling a little bit where in the IETF this draft can be
discussed and whether GROW is an appropiate group to further the
development of the document. 

Comments are most welcome!

Kind regards,

Job Snijders

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 22 Oct 2013 17:29:20 -0400

> Comments are most welcome!

The original RPS working group is defunct.  In such situations, the general
WG for the area would tend to pick up such work.

However, since GROW has recently picked up route-server work, which this
document is targeted for, GROW is probably a reasonable home for it.

Having reviewed this document (not in careful detail), the major issue in
-00 that was presented at NANOG has since been dealt with: The new feature
is present as an attribute of an existing RPSL class rather than trying to
alter the behavior of the existing attributes.  Per RFC 2622, sec. 10.2,
this should meet the requirements for safely extending the language.

I would support adopting this draft as a WG document.  If it is, I will
provide review on it.  I do, however, suggest that the WG attempt to
explicitly involve reviewers from RIPE, Merit, APNIC or other organizations
that operate RPSL repositories since they are the parties most impacted by
these changes.

-- Jeff

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 23 Oct 2013 15:45:52 +0800

> that operate RPSL repositories since they are the parties most impacted by

the draft has been discussed to some degree in the database working group
at RIPE, but you're right that it would probably be best to confer with
other RIRs too.

My thoughts on the draft is that per-se there is nothing wrong with it, and
it will provide a backwards-compatible mechanism for an interesting
attribute which is relevant to ixp route server connectivity. The rationale
for using a new class attribute is that it's not possible to shoe-horn the
required semantics into mp-{import,export}.

And this is the problem: RPSL is broken enough that it's not possible to
extend the language in a backwards compatible way, and the only option for
stuff like this is to create a completely new class for an incremental
feature upgrade.  Although I have no particular objection to this draft, I
think it shows that RPSL is too broken to put much serious development into
it, and that it would be more productive to look at creating a new alternative.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 23 Oct 2013 21:31:36 +0800

On 23/10/2013 21:28, Jeffrey Haas wrote:
> Secondly, the amount of work that went into even getting as far as RPSL from
> RIPE-181 was daunting.  I'd think very hard before considering such work.

if it had been easy, someone would have done it long ago because we all
need automated tools for handling our network devices.

Nick

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 23 Oct 2013 09:28:20 -0400

Nick,

> required semantics into mp-{import,export}.

Agreed.

For historical reference, the RSng route-servers provided this functionality
at the inet-rtr level rather than aut-num.  (Attributes rs-in and rs-out)

The aut-num level as specified in this document is a bit more general and
centralizes the functionality a bit better than inet-rtr.  However, I don't
have a strong opinion whether the updates in this draft are in inet-rtr vs.
aut-num.  

Carrying import-via/export-via in inet-rtr does have the possible advantage
that the sieving mp-peering-1 in the draft simply drops out and is a side
effect of the specified inet-rtr.  However, exchange points often have more
than one router and this means that policy is duplicated.

> it, and that it would be more productive to look at creating a new alternative.

Firstly, the I2RS folk would probably like to talk to you about this. :-)

-- Jeff