# SIDROPS @ IETF 118   {#sidrops--ietf-118}

Minute taker: Job Snijders  
Chair: Russ Housley

Chair welcomes everyone and reminds the group to adhere to the "note
well"

No objections were made to the agenda as proposed.

## Chair update on rfc8210bis   {#chair-update-on-rfc8210bis}

ASPA RTR plan:

*   First finish up ASPA Validation & Profile drafts and WGLC them.
*   Then proceed to rework the RTR extension for ASPA (rfc8210bis).

No objections

## Sriram Design Analysis of RPKI Prefixlist   {#sriram-design-analysis-of-rpki-prefixlist}

An RP can discard BGP updates that are originated by a given AS that
created a RPKI PrefixList and didn't list the prefix in the BGP update.

Internet-Draft doesn't answer whether it's exact matching or
more-specifics are also permitted.

Validation states currently are: invalid & not invalid.

Sriram iterates over a number of problems solved by RPKI PrefixList.

Geoff Huston asks why is it bogus from the RP perspective? ROAs are not
bogus when prefix isn't listed on the PrefixList. ROA is a one-way
authority.

Ties de Kock comments "Doesn't ASPA solve this better?" Sriram will
return to the question.

Sriram moves on to reflect on Operational Considerations for splitting a
prefix, or adding a new prefix.

Job Snijders provided suggests that we should not try to be 'clever' by
optimizing aggregation; instead, strive for 1:1 mapping between BGP and
PrefixList. AS\_SETs should just be killed as suggested in Warren's
Internet-Draft.

Tim Bruijnzeels might see some value in NotFound state, but doesn't feel
super strong.

Warren suggests 'egress verification' on the AS EBGP router so that
people can easily see mismatches between PrefixList and actual router
configuration.

Geoff Huston agrees with everything Job said. Don't *discard* the BGP
UPDATE; instead, keep it in Adj-RIB-In.

Ben Maddison suggests a third-state for diagnostic purposes isn't
needed, because it is super easy to see if an AS has a PrefixList or
not. Suggests a paragraph to explicitly mention BGP updates should be
stored in Adj-RIB-In.

Rüdiger Volk says that "source representation" for the prefixlist takes
same syntax for IP address notation in RPSL, which is a quadrupple.
Rüdiger prefers to implement RPSL route-set expressions because its very
powerful.

Ties de Kock asks a question about ASPA: Ties wants to compare all
RPKI-based technologies in partial deployment scenarios to help
understand priorities. Ties will work on this to answer it himself.

Ben Maddison suggests that the object be a flat simple list; and instead
in a user interface a "RPSL to RPKI Prefixlist"-converter is provided.
Doing RPSL expressions in ASN.1 is too hard. On-the-wire encoding should
be as simple as possible.

Job repeats that maintaining proper Adj-RIB-In is the best solution.

## Operational Granularity of RPKI ROA Management - Yanbiao Li   {#operational-granularity-of-rpki-roa-management---yanbiao-li}

More than half of BGP routes are covered by ROAs, but ROV is lagging.

CSTNET doesn't issue ROAs yet, because it perceives operational risks.
Human error is the big risk, but even without human error the presenter
sees issues.

Problem 1: Dillema in setting maxlength.

Rüdiger Volk and Ben Maddison interrupt the presenter and ask for an
explanation of the problem, because the ROA profile allows functionality
exactly matching what the presenter is showing; there some confusion
what problem is being raised.

Job Snijders interrupts the presenter and points out that a single ROA
can contain multiple prefixes, and RPKI Manifests are used to provide
'atomic update' mechanism. Job is happy to elaborate off-list on ROA
encoding and manifests in more detail.

Presenter suggests to extend ROA to also use bitmasks.

Chair Russ reminds the group that there is 5 minutes left.

## Wrap Up   {#wrap-up}

Chair Russ: There have been some hallway discussions about some
remainging concerns with the ASPA Internet-Drafts. If there was time, we
would have discussed those concerns under the "Any Other Business"
agenda item. We do not have time for that discussion. Please take it to
the mail list.

Chair Russ: IETF 118 closed a minute ago, so is this session now over
too.