Re: grow: minutes/notes for GROW, IETF-58

[David Meyer <[e-mail]>]

---

On Fri, Nov 14, 2003 at 05:10:27PM -0600, Tom Barron wrote:
>> 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 :-)


	Thanks Tom. I know how hard it is to take minutes while
	trying to participate. I would have done the normal WG
	chair editing, but the the best of my knowledge, there is
	no WG. In any event, I appreciate the effort and thank
	you for posting what you had.

	Thanks,

	Dave


>> 
>> - 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/
____________________________________________________________
Web Archive:     http://darkwing.uoregon.edu/~llynch/grow/