Subject: Re: Last Call: draft-haberman-rpsl-reachable-test (An RPSL Interface Id for Operational Testing) to Proposed Standard

From: Vesna Manojlovic <[email-masked]>
Date: Thu, 18 Mar 2010 12:48:55 +0100

Dear Brian, list,

On 3/6/10 12:28 AM, The IESG wrote:
> 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
> [email-masked] mailing lists by 2010-04-02. 

I support the introduction of the new attribute.

At the RIPE NCC, we already see opportunities for its usage for 
reachability testing and analysis.

> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-haberman-rpsl-reachable-test-03.txt

One suggestion: please add that the pingable address MUST be within the 
range specified in route(6) object.

It is implicit, and obvious, but for people implementing the IRR code
(RIPE Database server, IRRd) it should be specified explicitly (IMHO), 
so that they can program the checks...

I am looking forward to the acceptance of this addition to the RPSL 
specs, and I am willing to assist in the implementation & adoption of 
the new attribute.

Regards,
Vesna Manojlovic
RIPE NCC Trainer

---

From: Larry Blunk <[email-masked]>
Date: Thu, 18 Mar 2010 10:39:10 -0400

Vesna Manojlovic wrote:
> One suggestion: please add that the pingable address MUST be within 
> the range specified in route(6) object.
>

   I'm still not entirely convinced that this belongs in RPSL
as opposed to the address registry allocation information.
There are often suballocations of addresses where there is no
change in origin AS and thus only a single route object exits.
It would be useful to be able to indicate pingable addresses in these
suballocations.   While one could have multiple pingable attributes in the
route object, I believe it is cleaner and clearer to put the
pingable address in the suballocation information.

   I have concerns about these pingable addresses becoming
stale.    I'd like to see some caution in the draft about this
issue and the possibility of mis-interpreting a stale address
as a routing issue.  One might suggest using the date in the changed:
attribute as a possible indicator of staleness.    You could
also add an explicit date field to the pingable attribute itself.
Another possible option would be to make this date an expiration
date set at some point in the future.   This would require periodically
re-verifying the address and updating the expiration date.
Pingable addresses with expired dates could be given less
credence than those that have not expired.

 -Larry Blunk
  Merit