Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New IX-F JSON importer procedure #474

Closed
arnoldnipper opened this issue Apr 14, 2019 · 3 comments
Labels
Milestone

Comments

@arnoldnipper
Copy link
Contributor

@arnoldnipper arnoldnipper commented Apr 14, 2019

In #351 there is a lot of discussions on how to properly import IX-F JSON files. There are two issues basically

  • how to act on state or to disregard it at all

  • what to do if fields differ, e.g. customer set is_rs_peer to true, IX set it to false

Completely ignoring seems not to be wise as some IXes are using "state": "inactive" for whatever reason. Ignoring this state could hence lead to creating a netixlan for this ASN.

Hence we are defining two equivalence classes based on the values currently seen.

  • Act on class

    • state is in [ null, "active" "connected", "operational"]
    • on "Allow IX update" == "true"
      • create the netixlan if it didn't exist
      • modify the netixlan if it exist and differs
      • noop else
    • on "Allow IX update" == "false"
      • delete the netixlan iff there is a mismatch in the triple (asn, ipaddr4, ipaddr6)
  • Ignore class

    • state is in ["inactive"]
    • on "Allow IX update" == "true" a netixlan is not created
    • noop on any existing netixlan

Now we still have to define what to do with ASN which are in the IX-F JSON import and not in PeeringDB and vice versa.

  • if an ASN is in the IX-F JSON import and not in PeeringDB

    • noop
  • if an ASN is not the in IX-F JSON import, but is in PeeringDB

    • delete the netixlan
@grizz

This comment has been minimized.

Copy link
Member

@grizz grizz commented Apr 17, 2019

@arnoldnipper want to change how member types are acted on now as well?

It currently allows peering, ixp, routeserver, and probono

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Apr 17, 2019

According to the latest version, it's now

member_type": {
"description": "Participant type: peering, ixp, pro bono, routeserver or other",
"type": "string",
"enum": ["peering","ixp","other"]
}

From an importer pov I don't see that it would make sense to act differently on the member_type. Do you?

@grizz grizz added the Major label Apr 18, 2019
vegu added a commit that referenced this issue Apr 18, 2019
- clean up wording for import preview
- change `skip` action to `ignore` in import preview
- change action to `noop` when no action is taken because of disabled ixp update
- #390 fixed: Wrong IPs in exports for IX members with multiple links
vegu added a commit that referenced this issue Apr 18, 2019
- clean up wording for import preview
- change `skip` action to `ignore` in import preview
- change action to `noop` when no action is taken because of disabled ixp update
- #390 fixed: Wrong IPs in exports for IX members with multiple links 

merged from dev branch
grizz added a commit that referenced this issue Apr 18, 2019
- clean up wording for import preview
- change `skip` action to `ignore` in import preview
- change action to `noop` when no action is taken because of disabled ixp update
- #390 fixed: Wrong IPs in exports for IX members with multiple links
@grizz

This comment has been minimized.

Copy link
Member

@grizz grizz commented Apr 23, 2019

I don't think it makes sense to operate differently based on member type either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.