grow: minutes/notes for GROW, IETF-58

[Tom Barron <[e-mail]>]

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/