draft ptomaine minutes

Mark Knopper mknopper at cisco.com
Tue Jul 16 08:00:49 UTC 2002


Hi. Here are draft minutes of the Ptomaine meeting. Thanks to Sean McCreary
for being Official Scribe, and to Hal Peterson for unofficial notes.

Please note item 2(a) below, and send comments to the list on the IPv6 EC
issue for the redist-communities draft.

Also please send any corrections or comments.

    Mark


======

Prefix Taxonomy Ongoing Measurement & Inter Network Experiment (ptomaine) -
Minutes

Agenda slides here: http://bgp.nu/~mak/ptomaine_yokohama.ppt
                    http://bgp.nu/~mak/ptomaine_yokohama.pdf

TUESDAY, July 16 at 1300-1400  Room 503
=======================================

CO-CHAIRS:   Sean Doran <smd at ab.use.net> [not present]
             Mark Knopper <mknopper at cisco.com>

AGENDA:

1. Administrivia                              7 minutes
   General Discussion: ptomaine at shrubbery.net
   To Subscribe: majordomo at shrubbery.net
   In Body: subscribe ptomaine
   Archive: http://www.shrubbery.net/ptomaine
  Scribe? [Thanks to Sean McCreary.]
  Blue Sheets
  Agenda Bashing   


2. Discuss Working Group Drafts:

a. draft-ietf-ptomaine-bgp-redistribution-00.txt (15 mins - O. Bonaventure
et. al.)

Andrew Lange on representing IPv6 in redistribution communities.
Problem is that there isn't enough space in the 64-bit EC value to
represent 128-bit IPv6 addresses.  Andrew proposes variable-length
ECs.  This is a proposal to modify extended communities set to have:
        one octet length field
        variable length data field
        
        eliminating regular type
                force all communities to have type and subtype
                type defines format of data field
                subtype would provide clarification of interpretation
He will send email to IDR list with detailed proposal. He proposes to hold
this ptomaine draft until it can be updated with the final EC solution.

Hal Peterson:  Changing syntax and semantics of extended communities out of
scope.  What we have now solves existing problems, so we should proceed
rather than waiting for IDR to approve changes to extended communities.

There was no consensus to these opposing viewpoints, and document authors
were not present. Therefore we will take the discussion to the mailing list.


> Question on list:  what about convergence time impact of redist
> communities?  Mark asks for information, but does not see need to hold
> draft for it.
> 
> Also on the list, somebody suggested adding a wildcard for `always add
> NO_EXPORT'.
> 
> tbarron:  concern about community pollution; it is a valuable feature
> of the proposal that redist community is defined as nontransitive.
> That is value above and beyond the codification of existing practice.

Andrew Lange: `pollution' of routing table with excessive communities is a
        configuration error, the example presented at NANOG will be cleaned
        up by stripping communities at their ISP's boundary


b. draft-ietf-ptomaine-nopeer-00.txt (10 mins - Geoff Huston)

Consensus by hum (and approval by Randy as AD) to progress this document as
BCP. IANA considerations (to reserve a well-known community value) can go
forward in a BCP. Mark will issue last call on list.


3. Presentation on BGP trends (20 mins - Cengiz A. )

Slides can (currently) be found here:
http://bgp.nu/~mak/cengiz.pdf

Cengiz Alaettinoglu presented `Recent BGP Trends', an update of the talk
        he gave at the London IETF

The data was from RIPE/RIS, containing all BGP messages not just table
        snapshots

Time period: Dec 2000 - July 2002
        
Routing table growth rate has slowed dramatically, both in absolute slope
and in big-Oh.

`Historic' prefixes:  classful prefixes that are usually replaced by a
        covering CIDR aggregate prefix in the core routing table
        Without CIDR, routing table would be 5x larger to hold all the
                `historic' prefixes

Growth rate in historic prefixes is slowing
        Cengiz suggests this indicates new advertisements are not appearing
                in the core table due to a preexisting covering aggregate
                prefix?

Cengiz' taxonomy of prefixes:
        Multi-homing
        Engineered prefixes
        Punching holes
        Regular prefixes

Number of engineered and hole prefixes have decreased
Number of multihomed prefixes with multiple origins not growing

BGP churn per router:
        last year churn was slightly decreasing
        Trend has continued

churn per prefix decreasing even faster
        So overall stability is improving, total variability decreasing

Most churn (>75%) was from peering loss
        This continues to be a problem, although the collected uptime data
        is for multihop peerings, which are likely to be less stable than
        conventional ones

Summary:
        Table growing
        BGP churn decreasing, decelerating
        engineered prefixes no longer churn more than their share
        peering loss/reestablishment still a problem


Geoff: do you differentiate between advertisements/withdrawals and path
        changes
        Path changes are becoming more stable, but withdrawal numbers
                increased substantially in April 2002
This may have to do with large-scale changes in the core, with the demise of
some carriers.


Dan Massey presented a graph of BGP message classification from RIPE/RIS
        data

Randy Bush: 95% of the session resets are due to measurement artifacts (EBGP
        multihop) rather than real problems

Dan: We don't see session resets from non-multihop peerings either


 Geoff's graphs can be found at http://bgp.potaroo.net

Randy, Mark and others called for others to post any current BGP
measurements or analysis to the ptomaine list.

4. Charter review & call for contributions (8 mins)

Mark revisited the charter:
        This working group has a role to play, but doesn't have any
        outstanding standardization issues to discuss
        Last milestone in the charter was dated FEB 02
        If no more documents are submitted, then working group should go
        dormant in a month

Questioner:  Ptomaine has been a useful forum for measurement presentations
        like Geoff's. Randy (AD) agreed.

Mark: Ptomaine fills a role like the CIDR deployment working group did

David Ward: One month is too short an interval to close down the working
group
        It would be better to just not meet for awhile, but keep the
        mailing list and the working group open
        
Ed Kern:  You could always just consider a recharter.  That could take more
        than a year.





More information about the Ptomaine mailing list