Re: [[e-mail]: grow: minutes/notes for GROW, IETF-58]

[Tom Barron <[e-mail]>]

On Fri, Nov 14, 2003 at 06:34:03PM -0600, Tom Barron wrote:
> Dear IESG,
> 
> In support of my claim that the first part of the GROW meeting
> was productive and on target, here are the minutes I took.
> 
> After the final presentation was made there were a few moments of
> productive discussion, then somehow the discussion spun into a venting
> session on grand issues about the mission of the IETF.  It would be
> overly easy to say that the chair of this meeting should have cut off
> that conversation and gotten it back on track.  Look at the list of
> folks at the mike at the end of the meeting (the conversation was
> quite fast, and some attributions may be incorrect, but the flavor is
> right.) and ask yourself how easy it would be to shut down many of
> those folks, including the AD at the time.
> 

I just want to make it clear I realize upon rereading that the
previous paragraph may sound like a criticism of the way the meeting
was chaired, but that's not what I intended at all.  I'm *glad* that he
ran a fair and open meeting and only regret that others have not been
equally so.

- Tom

> My plea is that the IETF not lose sight of the good and relevant work
> being done, that GROW be sustained as a WG in which it can be done,
> and that it not be a casualty of this little soap opera incident.
> 
> - Tom
> 
> ----- Forwarded message from Tom Barron <[e-mail]> -----
> 
> Date: Fri, 14 Nov 2003 17:10:27 -0600
> From: Tom Barron <[e-mail]>
> To: [e-mail]
> Subject: grow: minutes/notes for GROW, IETF-58
> User-Agent: Mutt/1.4i
> Precedence: bulk
> 
> I'm going to send out my minutes for this one while the email list
> is still there, without taking the time I normally would for the
> Chairs to review and correct, etc.  Please bear with (and correct if you
> want) various omissions, missed attributions, etc.  I was not able to
> keep up with the pace of the discussion at certain points :-)
> 
> - Tom
> 
> ===========
> GROW WG - IETF58 Mpls, 13 November 2003
> ===========
> 
> Administrivia:
> 
> Dave moderates, Vijay not present.
> 
> Agenda Bashing - none.
> 
> ----
> Generalized TTL Security Mechanism - draft-gill-gtsh-04.txt
> 
> Dave reviewed the motivations for generalizing what was initially
> intended as a security mechanism to protect BGP speakers - now it can
> be used for BFD, MSDP, etc.  Language has been generalized to be IPv6
> compliant, sanitized to meet marketeer's concerns about the word
> "hack", etc.
> 
> Dave called attention to the Security Considerations section,
> especially the discussion of why TTL/hop limit spoofing is hard, and
> the discussion of tunnelling, MPLS, and the like.  He solicited
> feedback especially on these areas.
> 
> No real discussion here, so comment on the list was encouraged.
> 
> ----
> Danny McPherson: Med Considerations: draft-mcpherson-grow-bgp-med-considerations-00.txt
> 
> Danny isn't here.
> 
> ----
> 
> Dave Plonka:  Embedding Globally Routable Internet Addresses Considered Harmful
> 
> Dave summarized the draft, which he wants to move towards a BCP, as
> well as the history at U. Wisc wherein a router vendor shipped
> thousands of boxes with the IP of a U. Wisc ntp server.  The routers
> in question had to be on the Internet to work right (couldn't run
> networks without an ntp server at that globally routable address),
> couldn't use servers with different addresses, and effectively
> blackmailed U.Wisc into providing a high volume service, which, if
> isolated form the campus net, meant that an entire class B couldn't be
> announced.  Pursuing this situation, Dave discovered other cases where
> vendors have put globally unique IP addresses in fixed configurations
> (e.g. firmware), and where documentation examples use real
> (nonRFC1918) addresses that are then configured inito lots of
> machines.
> 
> This draft recommends that product designers not assume their product
> will be used on The Internet rather than in private networks, that
> they use DNS names rather than IP addresses, and that they use RFC1918
> addresses for defaults and for their documentation examples.  It
> recommends that operators and service providers advertise suitable
> local services via DHCP 42 and that they stop listing IP addresses
> as identifiers in service directories and indexes.
> 
> In discussion it was observed that although it might seem obvious that
> use of globally routable addresses in this way violates netiquette and
> the rules of engagement for public services, and although the IETF has
> no actual power to prevent poor implementations (didn't catch who), it
> isn't obvious to everyone even within the IETF (Dave Meyer), and it is
> very valuable to be able to tell vendors that they are violating
> RFCxxx (Perry Metzger).  There was a suggestion (who?) that IANA reserve
> more objects for private use, a la RFC1918.  IPv6 private prefixes
> were brought up (Tom Patch) and the common use of public IP addresses in
> educational examples  (Tom Patch).
> 
> Should GROW adopt this draft?  Resounding "yes" from the assembled group.
> 
> ---------
> 
> DMM: BGP communities for data collection.
> 
> Dave summarized the draft and its motivation.  Route-views et. al.
> have tons of archived data, full of a mismash of community values from
> different providers.  A lot of information is encoded about the origin
> and type of route, but that information is effectively unavailable because
> of the lack of standardization.  Dave's draft defines BGP routes in terms
> of whether they are advertised from "peers", "customers", "providers", etc.,
> and provides a scheme for coding their geographic origin.  If service providers
> were to use this scheme the data at Route-views et. al. would be much more
> meaningful.
> 
> There were suggestions from the assembly (Randy Bush, Tony Tauber, Vince Fuller,
> others) that Dave modify the language used for his taxonomy of
> "peers", "customers", "providers", etc. to reflect the service
> provided or received (transit or not, etc.) rather than the economic
> arrangement between BGP neighbors.
> 
> There was discussion (Sean McCreary, others) of whether one's own ASN should
> be encoded in the community (as proposed) or whether a well-known ASN sould
> be used instead.  4-octet ASNs were brought up (Tom Patch) and a suggestion was
> made (Geoff Houston) about how to flip some bits in the proposed encoding for
> extended communities and accomodate bigger ASNs today.
> 
> It is expected that these issues can be discussed further on the list.
> 
> Should GROW adopt this draft?  Resounding "yes" from the assembled group.
> 
> -------
> 
> Dave Meyer: Routing Protocol Overload Draft.
> 
> Dave Meyer reviewed the presentation from the Routing Group meeting, where it
> proved to be a contentious issue.  There has not been much discussion on
> the list.  This draft presents two models of BGP, each of which tends to
> be tied to a different set of concerns about application fit, risk, and
> interference.
> 
>    1. General Purpose Transport Infractructure Model
>       carry lots of applications
>          - already happened with multiprotocol BGP
>       focuses on application fit questions
> 
>    2. Special Purpose Transport Model
>       BGP was developed specifically for IPv4 IDR
>       focuses on issues about interference and risk
> 
> Dave said this is an early version of the draft and that he would very
> much appreciate readers and on-list discussion.  He reiterated that
> this document just attempts to frame the issue rather than taking a
> stand on one model over the other.
> 
> John Scudder plugged IDR meeting drafts on Inform/Soft-Notify,
> Update-v2, and on multisession BGP, all of which address application
> separation issues very relevant to the separation and fate-sharing
> concerns discussed in this draft.
> 
> Should this draft be taken up by GROW?  A fast and furious discussion
> followed.  It was too rapid for this scribe to capture it all.  At issue
> were at least the following:
> 
>    To what extent should software engineering issues be addressed
>    in this draft?  In IETF?
> 
>    Are these so-called software engineering issues really system
>    architecture issues?
> 
>    Does this draft actually address operational issues? (I believe
>    that Randy Bush, with AD Hat on, said an emphatic "yes, because
>    poor system architecture causes operational outages.")
> 
>    Is the business of IETF just protocol specification or the
>    architecture and design of the system that is The Internet?
> 
>    Whatever your answer to the above, is that a Good Thing or a
>    Bad Thing?
> 
>    If the IETF should be concerned with software architecture for the
>    Internet but has abdicated its responsibility, should that be addressed
>    in this group (bottom up), at ISOC (top down), or somewhere in between?
> 
>    What is the role of the market, and what is the role of a central
>    planning/design body for the future of the Internet?
> 
> Participants in the discussion included at least the following: Yakov
> Rechter, Sean McCreary, Tony Li, Tom Patch, Vince Fuller, Randy Bush,
> Pekka Luoma, Lixia Zhang, Ross Callan, Bill Fenner, Dino Farinacci, and
> Geoff Houston.
> 
> Somewhere in the course of the discussion Randy Bush resigned as Ops
> AD, effective tomorrow (end of this IETF session).  The discussion was
> sufficiently fast and furious that I was not able to record Randy's
> explanation.
> 
> The GROW meeting ended with Dave Meyer's observation that although it
> had initially seemed that there was support for GROW adopting this
> draft, the issues actually discussed in response to the draft are
> clearly beyond the scope of the Global Routing Operations Workgroup.
> 
> ____________________________________________________________
> Web Archive:     http://darkwing.uoregon.edu/~llynch/grow/
> 
> ----- End forwarded message -----
> ____________________________________________________________
> Web Archive:     http://darkwing.uoregon.edu/~llynch/grow/
____________________________________________________________
Web Archive:     http://darkwing.uoregon.edu/~llynch/grow/