Re: IPv4 outage at next IETF in Chicago

John C Klensin <john-ietf@jck.com> Thu, 26 January 2017 17:08 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21E21298AA for <ietf@ietfa.amsl.com>; Thu, 26 Jan 2017 09:08:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.098
X-Spam-Level:
X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Vlv1rc2PxVc for <ietf@ietfa.amsl.com>; Thu, 26 Jan 2017 09:08:22 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E74D812989E for <ietf@ietf.org>; Thu, 26 Jan 2017 09:08:21 -0800 (PST)
Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1cWnX2-000JAA-Gk; Thu, 26 Jan 2017 12:08:20 -0500
Date: Thu, 26 Jan 2017 12:08:14 -0500
From: John C Klensin <john-ietf@jck.com>
To: Lee Howard <lee@asgard.org>
Subject: Re: IPv4 outage at next IETF in Chicago
Message-ID: <54CA64795300BE3B39625CD4@PSB>
In-Reply-To: <D4AF85EB.6DF1F%lee@asgard.org>
References: <844840869.114000858.1485299485194.JavaMail.zimbra@peachymango.org> <20170124235626.042F960836B0@rock.dv.isc.org> <158901d276b3$387d6050$a97820f0$@huitema.net> <CAAiTEH_4WgdmMZQm5nbFbvweibkZ0DAo2feN91zftspD4EbWjg@mail.gmail.com> <WM!572ad9a6ae19416c99bd6357d98a5df59a81b46a887701f7fe5b0c3faf7d1 57d9ed99107720fab7bcb2711df4ea4ce8c!@mailstronghold-3.zmailcloud.com> <1350087674.115436952.1485371218219.JavaMail.zimbra@peachymango.o rg> <b30cb454-f35a-f5d4-01ec-9d4a3d3b494f@krsek.cz> <CAHw9_i+HdOuP-OphT_KvG4mrdvMMCeCJuX+CzL8sq+bQ8zCgpQ@mail.gmail.com> <D4AF85EB.6DF1F%lee@asgard.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.70
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/up10av4nezzf6tsFMBfQbzmUD2k>
Cc: "ietf@ietf.org Disgust" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jan 2017 17:08:23 -0000

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@asgard.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.
>...