Skip to content

Conversation

kormat
Copy link
Contributor

@kormat kormat commented Sep 26, 2019

Disallowing them is something you'd only want to do in very specific
circumstances.


This change is Reviewable

Copy link
Contributor

@shitz shitz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion (waiting on @kormat)

a discussion (no related file):
I disagree with allowing ISD loops by default. It just further adds to the explosion of number of beacons and the core of the network should be well enough connected to not rely on these types of paths (by default). Can you give a reasoning why they are generally beneficial?


Copy link
Contributor Author

@kormat kormat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion (waiting on @shitz)

a discussion (no related file):

Previously, shitz wrote…

I disagree with allowing ISD loops by default. It just further adds to the explosion of number of beacons and the core of the network should be well enough connected to not rely on these types of paths (by default). Can you give a reasoning why they are generally beneficial?

The beacon explosion is not something that will hurt us in the short-term, and is something we need to fix regardless of this. On the other hand, even our default testing topo will break if the single link between the core ASes in ISD2 fails.

They are "beneficial" in the sense that you're not arbitrarily throwing away perfectly good connectivity.


Copy link
Contributor Author

@kormat kormat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion (waiting on @shitz)

a discussion (no related file):

Previously, kormat (Stephen Shirley) wrote…

The beacon explosion is not something that will hurt us in the short-term, and is something we need to fix regardless of this. On the other hand, even our default testing topo will break if the single link between the core ASes in ISD2 fails.

They are "beneficial" in the sense that you're not arbitrarily throwing away perfectly good connectivity.

(with the pull model for core beaconing the whole question goes away, too)


Copy link
Contributor

@shitz shitz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion (waiting on @kormat)

a discussion (no related file):

Previously, kormat (Stephen Shirley) wrote…

(with the pull model for core beaconing the whole question goes away, too)

OTOH, SCIONLab will be hurt by this. It's arguable whether this should be default, since connectivity within an ISD should be more reliable than across ISDs. Disallowing it would also filter out more degenerate cases where a single ISD is crossed three or more times. The point might be moot with the core beaconing redesign, but I'd rather see it as "exceptionally allow ISD loops" rather than "exceptionally disallow them".


Copy link
Contributor Author

@kormat kormat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion (waiting on @shitz)

a discussion (no related file):

Previously, shitz wrote…

OTOH, SCIONLab will be hurt by this. It's arguable whether this should be default, since connectivity within an ISD should be more reliable than across ISDs. Disallowing it would also filter out more degenerate cases where a single ISD is crossed three or more times. The point might be moot with the core beaconing redesign, but I'd rather see it as "exceptionally allow ISD loops" rather than "exceptionally disallow them".

It's a config option - scionlab can turn it to the desired setting. If you don't know that you need to disable isd loops, you shouldn't be disabling them - as again, you are throwing away perfectly good connectivity. If we look at our production + scionlab + our CI, they should be enabled for prod+CI, and not for scionlab. That doesn't seem like a convincing reason to have them disable by default.


Copy link
Contributor Author

@kormat kormat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion (waiting on @shitz)

a discussion (no related file):

since connectivity within an ISD should be more reliable than across ISDs

This is a non-argument. "more reliable" != "can't fail". And it can fail.


Copy link
Contributor

@oncilla oncilla left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 2 of 2 files at r1.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @shitz)

a discussion (no related file):
Code wise :lgtm:
I let you two battle out, whether this change should go in.


Copy link
Contributor

@shitz shitz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

Reviewable status: :shipit: complete! all files reviewed, all discussions resolved

Disallowing them is something you'd only want to do in very specific
circumstances.
@kormat kormat merged commit 3f5c6e9 into scionproto:master Sep 27, 2019
@kormat kormat deleted the isdloop branch September 27, 2019 10:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants