Subject: [Netrqmts] updated network requirements draft

From: "[email-masked]" <[email-masked]>
Date: Mon, 08 Jul 2019 21:42:43 -0400

Folks,

I have submitted an update (-01) to the network requirements draft (see 
pointers below). However, there is still much to be fixed and much 
missing from the draft.

I originally chose for the -00 to be the exact text developed originally 
so that there would be transparency in what was added and removed. 
(https://www.ietf.org/how/meetings/admin/meeting-network-requirements/)

In hindsight, perhaps that wasn’t the wisest choice but hey… you 
live and learn…

This document represents three sets of requirements:
1) Requirements for external connectivity providers
2) Requirements for the meeting venue
3) Requirements for the network that the IETF NOC Team builds
These are perhaps not as clearly differentiated as they should be.

Also, we have not addressed any network requirements for the hotel rooms 
in this document as the original text also did not address it.

And finally, some sections of this still haven’t received any 
substantive review. But, tomorrow is another day…

Suggestions with text are most welcome.

Karen

A new version of I-D, draft-odonoghue-netrqmts-01.txt
has been successfully submitted by Karen O'Donoghue and posted to the
IETF repository.

Name:		draft-odonoghue-netrqmts
Revision:	01
Title:		IETF Meeting Network Requirements
Document date:	2019-07-08
Group:		Individual Submission
Pages:		8
URL:            
https://www.ietf.org/internet-drafts/draft-odonoghue-netrqmts-01.txt
Status:         
https://datatracker.ietf.org/doc/draft-odonoghue-netrqmts/
Htmlized:       https://tools.ietf.org/html/draft-odonoghue-netrqmts-01
Htmlized:       
https://datatracker.ietf.org/doc/html/draft-odonoghue-netrqmts
Diff:           
https://www.ietf.org/rfcdiff?url2=draft-odonoghue-netrqmts-01

Abstract:
    The IETF Meeting Network has become integral to the success of any
    physical IETF meeting.  Building such a network, which provides
    service to thousands of heavy users and their multitude of devices,
    spread throughout the event venue, with very little time for setup
    and testing is a challenge.  This document provides a set of
    requirements, derived from hard won experience, as an aid to anyone
    involved in designing and deploying such future networks.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Jul 2019 10:32:38 -0400

[email-masked] <[email-masked]> wrote:
    > In hindsight, perhaps that wasn’t the wisest choice but hey… you live and
    > learn…

    > These are perhaps not as clearly differentiated as they should be.

Surely there are some interactions in the requirements?
You've done a good job.

Detailed:
The original text said:
  " The primary link MUST provide at least 45Mb bandwidth in both directions,
    and SHOULD have at least 100Mb bidirectionally. (Note: Historically,
    bandwidth utilization peaked at 80Mb and averaged 35Mb."

and I found the "bidirectionally" part confusing to quickly understand.
I'm glad that it just says "both directions" now.

"The meeting facility The meeting facility SHOULD have UPS power"

Doubled words "The meeting facility"

" The IETF users MUST have access to the terminal room from ?? to ??."

I thought it was normally 24/7.

In general, I don't know what parts of the document are requirements on the
hotel/meeting space, and what parts are requirements from the IETF attendees
on the network.  Some of it reads like bits of an RFP to a contractor.

For instance, the requirement about a printer in the terminal room... I
thought that "we" normally just brought one.  Given physical drops and power,
that works fine.

Do we not now have physical drop requirements in the meeting rooms for
the chair table chromebook?  The drops for the A/V are mentioned already.
What about the RPI sensor nodes that report on wireless availability?

You asked if we are done running cables; I certainly have no idea, it's been
50 meetings since I was a NOC volunteer, but I thought it still happened when
it needed to.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-