Just a note of clairification is that I have experienced with regards to the frequency that unprotected waves go down.  The greater the distance, the more likely/frequently that it is to happen.  You brought up my SIX Extension.  I have waves across 3 geographically diverse paths.  On average there is a single wave outage once a month.  If it was not for the monitoring, I would not notice since the redundancy tends to failover quite well.  We even managed to survive prolonged outages of 10 and 20 days from Avalanches, and Mudslides.

Specifically the paths for this proposal between 511 and 1102 Grand will have 2 diverse paths.  One goes via Omaha, and the other one via Chicago.

Jeremy Lumby

Minnesota VoIP

9217 17th Ave S #216

Bloomington, MN 55425

M: 612-355-7740

D: 612-392-6814

F: 952-873-7425

[log in to unmask]

To be clear my messages are NOT intended to be a downvote for the proposal, I’m just intending to foster discussion.

I don't think https://www.micemn.net/technical.html needs major changes.  Maybe change “Operators are responsible for the costs of operating their remote switch and the links to the core switch.” to “Operators are responsible for the costs of operating their remote switch and the links [TOWARDS] the core switch.”

I think it's worthwhile acknowledging the distance to the proposed remote switch, the presumed lack of redundancy in the proposed backhaul.

re: reliability:  Is the lack of redundancy an accurate assumption, or would this be a protected wave?  AS3128 has some experience in this area [AS3128 assists in operations of a 1000mi+ fiber ring for multistate research and education, including through Minneapolis and Minnesota] so I wanted to ack that in general with distance comes decreased reliability, and eBGP stability is important since topology changes lead to packet loss during convergence.  I acknowledge we already have peers at MICE that are extensions out of Chicago [Google comes to mind].  I am also aware of the options that, for example, AS32621 provides in extending folks to Seattle IX as an opt-in value add, which is contrast to the ‘auto opt-in’ stance MICE route reflectors users enjoy.

re: distance: based on geography or your home AS stance, this change could result in a longer RTT between some networks.  AS3128 appears at exchanges other than MICE.  But if you are in this club you are probably aware that you already have this potential problem and either you deal with it or not.  Admittedly, our operations are less algorithmic and more reactionary.

So if I were to focus discussions on either distance or reliability, I would focus more on reliability.  Ultimately with MICE per-AS BGP community support, the publication of https://www.micemn.net/participants.html, and mailing list announcements of when new peers are brought onboard, AS3128 has all the tools it needs ==IF== we need to make a traffic engineer decision, which is great.

If NOCIX comes onboard, I would welcome them and would have no intentions to proactively traffic engineer away from them via MICE.

-Michael

Our agreement with MN VOIP would be for transport from KC to Minneapolis.  If the link became congested, we would order additional capacity.  If MN VoIP could t provide it then we would get it someplace else.  In the end, our intention is to be congestion free from KC to the MICE core.

To unsubscribe from the MICE-DISCUSS list, click the following link:
http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

To unsubscribe from the MICE-DISCUSS list, click the following link:
http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1