Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects

[Stavros Konstantaras via db-wg]

Hi Denis,

I support the idea of having empty AS-SETs deleted automatically and keeping 
only AS-NULL in the DB. 

@Edward Shryane question to the DB team: would it be possible to have some 
functionality in the LIR portal that converts the short-named AS-SETs to the 
hierarchical ones with a click of a button?  That would help people transition 
much easier and faster to the hierarchical AS-SETs. Perhaps a button that can 
be triggered by user and 1) creates a new hierarchical AS-SET 2) copies all 
elements from old AS-SET to the new one 3) Deletes the old AS-SET 4) Updates 
the corresponding import/export rules.  


Kind Regards
Stavros

On 23/11/2022, 17:58, "db-wg on behalf of denis walker via db-wg" 
 wrote:

Hi Niall

On Wed, 23 Nov 2022 at 00:30, Niall O'Reilly via db-wg  
wrote:
>
> On 22 Nov 2022, at 19:11, Nick Hilliard via db-wg wrote:
>
> > Careful with this, e.g. AS-NULL. There are some situations where
> > referencing an empty set can be useful in RPSL.
>
> I'm not sure whether Nick meant this as a single exception,
> or rather as an example of a category of useful empty sets.

One empty set is the same as any other empty set. We only need one
clearly defined and easily recognisable empty set and we have that,
AS-NULL. If I create an empty set, AS-WALKER it doesn't do anything
that AS-NULL can't do. But AS-WALKER isn't instantly recognisable as
an empty set. You have to query it to see that. If we have 100 empty
sets in the database, including AS-NULL, that are all being used for
valid reasons, 99 of them are redundant, duplicated objects and should
be deleted...unless someone can tell me the value of a duplicated
empty set.

cheers
denis
co-chair DB-WG

>
> I can well imagine that most "operationally empty objects"
> (as Denis put it) are either useless or troublesome.
>
> As Nick says, "Careful with this."
>
> Niall
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change 
your subscription options, please visit: 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe.net%2Fmailman%2Flistinfo%2Fdb-wgdata=05%7C01%7Cstavros.konstantaras%40ams-ix.net%7C3c1aa8fca7914446d88408dacd73e9da%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638048194975456541%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=tk2suM5OkDIBLif6XXQnKk05lSl0O3ua37Lc5ZtWPdU%3Dreserved=0

-- 

To unsubscribe from this mailing list, get a password reminder, or change 
your subscription options, please visit: 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe.net%2Fmailman%2Flistinfo%2Fdb-wgdata=05%7C01%7Cstavros.konstantaras%40ams-ix.net%7C3c1aa8fca7914446d88408dacd73e9da%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638048194975456541%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=tk2suM5OkDIBLif6XXQnKk05lSl0O3ua37Lc5ZtWPdU%3Dreserved=0

-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/db-wg

Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects

[Stavros Konstantaras via db-wg]

I support the idea as well.



Kind Regards

Stavros Konstantaras | Sr. Network Engineer | AMS-IX
Frederiksplein 42, 1017 XN Amsterdam, The Netherlands
M +31 (0) 620 89 51 04
ams-ix.net


From: db-wg  on behalf of Emil Palm via db-wg 

Reply to: Emil Palm 
Date: Wednesday, 16 November 2022 at 13:07
To: "db-wg@ripe.net" 
Subject: Re: [db-wg] proposal: disallow creation of new non-hierarchically 
named AS-SET objects

Solution proposal
=
I think the solution is to - GOING FORWARD - disallow creation of new
AS-SET objects which follow the 'short' naming style.

I support this solution

On Mon, 14 Nov 2022 at 18:41, Job Snijders via db-wg 
mailto:db-wg@ripe.net>> wrote:
Dear DB-WG,

Speaking in individual capacity.

In RFC 2622 section 5 specifies the naming convention for AS-SET
objects. 
https://www.rfc-editor.org/rfc/rfc2622#section-5.1
There basically are two styles:

* "short" (example: AS-SNIJDERS)
* "hierarchical" (example: AS15562:AS-SNIJDERS)

Problem statement
=
In recent weeks a number of hypergiant cloud providers have faced the
thorny effects of adversarial AS-SET object naming collisions between
IRR databases.

An example of this phenomenon is the existence of AS-AMAZON in both RADB
and RIPE. According to 
https://www.peeringdb.com/net/1418
 the RADB copy
of the object is the the correct one and populated with a number of
members entries. The RIPE one is empty, and not under control of Amazon.

The existence of the AS-AMAZON object in the RIPE database might cause
some operators to inadvertently apply empty prefix-filters to EBGP
sessions which in turn causes various problems.

It seems Amazon has no recourse to get the AS-AMAZON object removed from
the RIPE database; because the existence of that object in the RIPE
database does not violate any policies (as far as I know). But perhaps,
going forward, this community can do a little bit more to help prevent
similar situations from happening to others.

Solution proposal
=
I think the solution is to - GOING FORWARD - disallow creation of new
AS-SET objects which follow the 'short' naming style.

The advantage of hierarchical naming is that the existing authorization
rules as applied by the RIPE Whois Server database engine do a decent
job of protecting/separating namespaces. 'Grandfathering' existing
short-named objects ensures that implementation of this solution
proposal causes minimal (if any) disruption to existing workflows.

The RIPE database engine blocking creation of short-named AS-SETs might
help nudge the industry towards making hierarchical naming the norm.

Related work

Related work throughout the registry industry: IRRd version 4 forces new
AS-SET objects to be structured hierarchically:
https://github.com/irrdnet/irrd/issues/408

Kind regards,

Job

--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/db-wg
-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/db-wg

[db-wg] Problem definition for new NWI (12?) - NRTM service

[Stavros Konstantaras via db-wg]

Dear db-wg community,

Please find below the problem definition for the (upcoming) NWI-12 item as we 
have discussed it and envisioned it for this project. 


Problem definition:

Back on October 2019 during the RIPE 79 meeting in Rotterdam, we discussed 
about the  need to move forward with a next generation of NRTM service. Upon 
the completion of NWI-9 and the lifting of the legal restrictions, we can now 
proceed to design the new solution. As we discussed preciously, the version 3 
of the current NRTM solution is not suitable anymore for network operations on 
2020. A summary of the reasons are:

-Is a Telnet based protocol, thus:
• No keep alive mechanism is adopted, 
• It provides plain text/unencrypted transport of data

-The bootstrap process is not always trivial and sometimes is slow 
-Long time synchronisation is complicated and users need to re-synchronise 
after a couple of weeks. 
-No well specified protocol (There is just a PDF doc that describes it)

For all the reasons above (and reasons that we might have not think about yet 
but you are welcome to share), it becomes a necessity for the community to 
proceed with a new implementation that will be easily adopted by modern tools 
and last for the years to come. 


I hope the above text is sufficient for the db-wg chairs to kick off the 
process and the community to share its feedback. 


Best regards,

Stavros Konstantaras | Sr. Network Engineer | AMS-IX 
M +31 (0) 620 89 51 04 | T +31 20 305 8999
ams-ix.net

Re: [db-wg] Interest to continue NWI-9

[Stavros Konstantaras via db-wg]

Hi Dennis, 

I agree to close NWI-9 and proceed with opening of NWI-12 in order to explore 
ways
to modernise the NRTM service. With that said, please consider my interest also 
for
NWI-12. 


Best regards,

Stavros Konstantaras | Sr. Network Engineer | AMS-IX 
M +31 (0) 620 89 51 04 | T +31 20 305 8999
ams-ix.net

> On 29 Oct 2020, at 18:30, denis walker  wrote:
> 
> Hi Job
> 
> I would agree that NWI-9 is finished, according to the way it is
> worded. I would suggest we create NWI-12 to move forward with a new
> version of NRTM. Perhaps you could write the first draft of the
> problem statement?
> 
> cheers
> denis
> co-chair DB-WG
> 
> On Thu, 29 Oct 2020 at 18:09, Job Snijders  wrote:
>> 
>> Dear group,
>> 
>> I think NWI-9 needs to be reworded, it in part has been over taken by
>> current events. Rereading 
>> https://www.ripe.net/ripe/mail/archives/db-wg/2019-April/006236.html
>> what is described there actually already has completed.
>> 
>> RIPE NCC's NRTM servers are open to the public (this was not the case in
>> april 2019 yet). The NRTM servers can be used to *subscribe* to changes
>> in the RIPE database. When the NRTM client remains connected, it will
>> receive NRTM updates as they come in. THIS IS IN-BAND, AND FAST. The
>> rate of object change is very low compared to most information systems.
>> 
>> Looking at 
>> https://ripe79.ripe.net/presentations/118-NWI-9_S.Konstantaras_DB-WG.pdf
>> it is not clear to me what the problem definition is and how it relates
>> to the wording of NWI-9. The proposed optimisations are either not in
>> the RIPE IRR -> Cache layer (as NRTM is really near-real-time when
>> implemented correctly) but elsewhere in the end-to-end route server
>> functionality. From this perspective NWI-9 has already been completed!
>> 
>> Now, there is plenty to be left desired about NRTM v3. Even though it is
>> both a push and pull protocol and very fast (the push can measured in
>> single digit seconds), NRTM v3 clearly is an ancient protocol and the
>> operational community would benefit from a re-design of NRTM.
>> 
>> WORK IS UNDER WAY: LACNIC has committed funding for IRRd's NRTM v4
>> implementation. RIPE NCC's 'good for the Internet' community fund has
>> also been requested. That decision is still pending with the committee
>> operating that fund.
>> 
>> So what we have so far:
>> 
>>- A collective desire to replace NRTM v3 with something else
>>- The *only* two IRR server code bases of this industry have
>>  (partial) funding to make changes possible: IRRd and RIPE WHOIS server
>>- A standardisation forum to publish the new spec: IETF
>>- Multiple forums for input: RIPE DB-WG, IETF, *NOG, IRC, etc
>> 
>> If NWI-9 is kept open I would request it is reworded to the extend that
>> this working group requests RIPE NCC to commit to help design,
>> implement, test & adhere to what will become "NRTM v4".
>> 
>> I read Stavros' presentation where the above plan is listed as
>> 'Langzaam' :-) but the characterization may be a little bit off: there
>> is no Legal aspect to deal with: RIPE NCC made NRTM  freely,
>> contract-less, publicly and in real-time available already. Also keep in
>> mind that any new protocol will indeed need to be tested (even if
>> general purpose components such as JSON, HTTPS and WebSockets are
>> used!).
>> 
>> NRTM v4's design will have nothing to do with how NRTM v3 looks and
>> feels. NRTM v4 will be HTTPS based, I guarantee it! This project has
>> 'NRTM v4' as name to make it clear to the IRR operational community
>> where in the internet-stack this protocol belongs, but that it is an
>> improvement over version 3.
>> 
>> NRTM v4 can easily be something that is finished and deployed in 2021.
>> What needs to be done is fairly straight-forward, and lots of existing
>> tools can be used to make the job easier (like HTTPS and JSON).
>> 
>> Kind regards,
>> 
>> Job
>> 
>> On Thu, Oct 29, 2020 at 05:22:10PM +0100, denis walker via db-wg wrote:
>>> Hi Stavros
>>> 
>>> Thanks for the comment. I have let Ed know about your interest.
>>> 
>>> cheers
>>> denis
>>> co-chair DB-WG
>>> 
>>> On Thu, 29 Oct 2020 at 17:11, Stavros Konstantaras via db-wg
>>>  wrote:
>>>> 
>>>> Hi WG chairs,
>>>> 
>>>> 
>>>> I would like to declare that from our side we are still interested to team 
>>>> up with Ed and RIPE NCC coll

[db-wg] Interest to continue NWI-9

[Stavros Konstantaras via db-wg]

Hi WG chairs,


I would like to declare that from our side we are still interested to team up 
with Ed and RIPE NCC colleagues to continue the work on NWI-9 item 
in order to modernise the NRTM service with something better and more suitable 
for our current needs.

As far as I can recall, Ed and his team have several ideas to proceed forward 
with this subject, so I believe that we would be able to draw a clear 
development plan.
And as a kind reminder, not only us (AMS-IX) but the European IXP community has 
expressed interest on proceeding with that subject.


Thank you and we are looking forward to discuss further steps on the subject. 



Best regards,

Stavros Konstantaras | Sr. Network Engineer | AMS-IX 
M +31 (0) 620 89 51 04 | T +31 20 305 8999
ams-ix.net

Re: [db-wg] proposal: new attribute 'geofeed:'

[Stavros Konstantaras via db-wg]

Hi Job, all


> On 6 Oct 2020, at 18:28, Job Snijders via db-wg  wrote:
> 
> Dear DB-WG,
> 
> Some colleagues are working to address the never-ending-story of 'where
> the heck are IPs geographically?'. This problem space has been brought
> up numerous times in the Database Working Group, but we never managed to
> solve it. As with all compsci problems adding a layer of indirection can
> help ;-)
> 
> This current draft suggests overloading the RPSL 'remarks:' field with a
> structured attribute value, however I suspect we would do ourselves a
> disservice to overload a 'remarks:' field.
> 
> Instead it would be better to add a 'geofeed:' attribute to the RPSL
> inetnum/inetnum6 class dictionary, which as value contains a URL with
> http or https scheme.
> 
> The draft: https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds
> 
> The value of the attribute could be validated using something like
> "org.apache.commons.validator.UrlValidator", the attribute would look
> like this, only valid in the inetnum/inet6num:
> 
>"geofeed:   [optional]   [single] [ ]"
> 
> Example object:
> 
>inetnum:192.0.2.0 - 192.0.2.255
>netname:EXAMPLE
>country:NL
>geofeed:https://example.com/geofeed.csv
>... snip ...
>source: RIPE
> 
> What do others think?

Yes I find this much more reasonable instead of overloading the remarks field. 
By default the remarks are being ignored by the parsers as it doesn’t contain 
any usable information that can be used in the router config generation (or 
other type of config). They contain information for the operator/human that 
reads the file on his screen. 

By enriching the RPSL dictionary and having a “geofeed” RPSL attribute (which 
by the way should not be mandatory) will be easier for someone to extend his 
parser to use that field without overloading the parser with many “if” and 
regex expressions. Plus the upcoming RFC specifies that "The format MUST be as 
in this example,“ so a verification needs to be applied later on.

Of course it’s weird to talk about enriching RPSL on 2020 but putting this 
apart, I believe it’s more correct to implement it in this way.

 
> Kind regards,
> 
> Job
> 
> ps. In IRRd v4.2 support for the 'geofeed:' attribute will be added
> https://github.com/irrdnet/irrd/issues/396

Best regards,

Stavros Konstantaras | Sr. Network Engineer | AMS-IX 
M +31 (0) 620 89 51 04 | T +31 20 305 8999
ams-ix.net

Re: [db-wg] RPSL parser nits

[Stavros Konstantaras via db-wg]

Hi Lutz (and sorry for the late reply),

Maybe you can have a look on “PolicyParser” located here:
https://github.com/stkonst/PolicyParser 


It hasn’t received any commit the last 4 year, however It was working well 
until the moment I left the NLnet Labs.
And is python based, so it will be easy for reading and patching/expanding. 


Hope the above helps. 


Best regards,

Stavros Konstantaras | Sr. Network Engineer | AMS-IX 
M +31 (0) 620 89 51 04 | T +31 20 305 8999
ams-ix.net

> On 2 Jul 2020, at 17:21, Lutz Donnerhacke via db-wg  wrote:
> 
>> You may want to think twice about whether it's worth investing time and
>> effort in rpsl in 2020.
> 
> That's true, but I do need some style of machine readable documentation 
> internally as well as an slightly competent looking aut-num object for 
> peering purposes.
> 
> So the only choices are:
> a) invent something new for internal usage and update the RADB in addition.
> b) use the existing ideas and tools.
> 
> I do not have any problem in patching or rewriting software, if necessary.
> For solution a) I have to do everything by myself anyway, so where is the 
> difference to b), even if I'm the only user?
> 
> If the projects are abandoned, who is to contact to shift the responsibility?
> 

Re: [db-wg] Whois Release 1.97

[Stavros Konstantaras via db-wg]

Nice… 

Thank’s for the update Ed


Best regards,

Stavros Konstantaras | Sr. Network Engineer | AMS-IX 
M +31 (0) 620 89 51 04 | T +31 20 305 8999
ams-ix.net

> On 18 Mar 2020, at 16:02, Edward Shryane via db-wg  wrote:
> 
> Dear Working Group,
> 
> RIPE Database release 1.97 has been deployed to the Release Candidate 
> environment. We plan to deploy to production on Wednesday 1st April.
> 
> The major change in this release is to open the NRTM service (regardless of 
> membership status).
> 
> The release notes are on the website:
> https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-release-1.97
> 
> More information on the Release Candidate environment can be found on our 
> website:
> https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candidate-environment
> 
> Please let us know if you find any issues with this release in the RC 
> environment.
> 
> Regards
> Ed Shryane
> RIPE NCC
>