ietf
[Top] [All Lists]

Re: IPv4 outage at next IETF in Chicago

2017-01-26 11:08:37
Lee,

This strongly suggests that it would be a good idea for the NOC
to have a web-based reporting form that specifically asks for
(or, when possible, automagically fills in) whatever information
is needed to cause a ticket to make sense and be useful.  I'd
hate to see such a thing replace the email options -- if nothing
else, if one is trying to work around a problem but still report
it, it may be faster to get an email message out and that speed
may make the difference between a useful "something is wrong'
heads-up report and silence -- but the odds of many of us
spontaneously remembering a list of things that should be
included in a report are not very high.

best,
   john


--On Thursday, January 26, 2017 11:12 -0500 Lee Howard
<lee(_at_)asgard(_dot_)org> wrote:



An IPv6-only SSID already exists -- it's even currently called
"ietf-v6ONLY" (For users wanting pure IPv6 ).


I spend as much time as I can on that one, and have sent email
to the NOC about things that break. For me, Jabber was a key
one that kept me from staying there; I believe Google was
unable to authenticate my Jabber account over IPv6.
The unavailability of Github is another recurring problem,
when so many WGs store stuff there.

There is also
"ietf-nat64" (IPv6 stack with NAT64).

So I end up spending a lot of time on this one. Mostly works.

Question for you NOC folks: when I report a problem, how much
information do you need?
For instance, I can say, ³Jabber failed.²
Or I can say, ³Jabber failed, here¹s my account.²
Or I can say, ³Here¹s a packet capture of trying to log into
Jabber.² But I don¹t want to provide more data than is
useful.

Also, I don¹t know of any reporting on tickets like that.
That kind of reporting would help us understand what still
breaks on IPv6-only or NAT64, and therefore how much pain it
would be to make one of those configurations be the default
SSID. It would also help us focus pressure on the apps and
tools that break in such scenarios; if my Jabber problem turns
out to be authentication at Google, I could find somebody
there who might be able to help. Or if it¹s my client, I
might be able to find (or fund) the needed update.

Would you folks give us some guidance on how to report issues,
and provide some reports, so we can have metrics telling us
when we can reasonably make changes?


This information is regularly
communicated -- for example:
Jim's email "[97all] IETF 97 Network Information ­ Seoul,
South Korea" the IETF NOC reports - e.g: for IETF97 -
https://www.ietf.org/proceedings/97/slides/slides-97-ietf-ses
sa-noc-report -00.pdf
, Slide 6 shows associations per SSID. 3 on ietf-v6ONLY and
19 on ietf-nat64.

Thanks for that pointer; these reports often go by too fast.
I find it fascinating that ietf-legacy is significantly more
popular than ietf. Why is that?

As someone who's been involved in the NOC, I'm slightly
irritated by the "You should really supply X, everyone wants
it, how do I get this done?!" tone when it's been available
(and not very widely used) for many years, and that a few
seconds looking would have shown this.

Fair enough, and I understand the primary requirement for the
IETF network is to let people get their work done. So I¹m
trying to figure out how to list stuff that wouldn¹t work, so
we can clear the way, so we don¹t interfere with work.
...