grow: Re: draft minutes for IETF 62

["Tom Petch" <[e-mail]>]

I would like to see the URL for the last three presentations, in the minutes for
preference.

Tom Petch

----- Original Message -----
From: "David Meyer" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, March 17, 2005 10:33 PM
Subject: grow: draft minutes for IETF 62


> Thanks to our scribe and to Geoff for editing.
>
> Dave
> ---
>
> GROW Minutes
>     IETF 62
>     Thursday 10th March
>     9:00 - 11:30 am
>
>
> o Agenda Bashing
>   no changes to the agenda
>
> o Review and status of work items
>
>   Active Drafts
>   -------------
>
>   - draft-ietf-grow-bgp-med-considerations-02.txt
>     McPherson/Gill (expired)
>
>     The draft will be re-submitted to the drafts editor. The document is
>     ready for WG last call, which will be made once the draft is published
>
>
>   - draft-ietf-grow-anycast-00.txt
>     Abley/Lindqvist
>
>
>     The WG has adopted this as a WG document. The document includes a
>     summarized deployment history of anycast including intra-AS deployment.
>     The motivation for the document was the observed lack of a reference
>     document on anycast, no ontology or taxonomy, and the scaling issues
>     for anycast appeared to be not well understood. The draft covers goals,
>     protocols, physical and routing considerations for anycast.
>
>     Draft discusses data synchronization issues, node autonomy, multi-
>     service nodes. I may also be useful to clarify in draft when you do
>     inconsistent services: present IP but deliver different content from
>     different anycast instances.
>
>     Operations - monitoring issues, harder to check nodes are up, routing
>     is stable.
>
>     Concerns:
>
>         draft covers about multi-service issues, (tunnel risks) - but many
>         people do this. This should be added to the document.
>
>         V6 anycast problems, scoping issues.
>
>         may be DNS-centric.
>
>     WG Discussion:
>
>       Pekka Savola:  not clear to me what you mean by anycast node in
>         taxonomy?
>
>       Joe Abley :  The draft uses this term to refer to nodes in multiple
>         locations, globally distributed service in Internet. Nodes may be
>         collection of services anycast over IGP, and may look like single
>         instance to general Internet
>
>       Pekka: You may need to define 'whole' anycast architecture.
>
>       Joe:  May need more work on that
>
>       Dave Meyer:  When you said IGP related bunch of things. eg IGP
>         overlay of tunnels, global with respect to Internet topology, is
>         that the same?
>
>       Joe:  Yes. IGP can be contained to one location or global via tunnels
>         but the external routing visibility is the same
>
>       Kitamura:  It appears that there is a need to clarify taxonomy,
>         functionality. I propose anycast BoF for further discussion.
>
>
>       Dave:  V6 anycast needs to note, nothing stops injection of V6
>         unicast prefix into routing cloud in the same fashion as V4. This
>         constructs same kind of anycast service as V4. Its not the same as
>         V6 anycast a defined in the V6 spec, and they have to be
>         disambiguated. I think deprecate the V6 standard anycast
>         specification may be the way to go.
>
>
>       Pekka:  don't think this draft is DNS centric. Multi-service nodes
>         are a distraction. The main focus of document should be single-
>         service nodes.
>
>       Pekka:  MTU issues for the tunnels. need to document.
>
>       Geoff:  The appropriate action is to take the V6 Anycast
>         specification to V6 WG, and don't do anything to this  draft. Its
>         an open issue, and the standard V6 anycast specification that noone
>         can or does use, and its operationally irrelevant. This appears to
>         be a topic for the V6 WG to grapple. This anycast use draft is
>         adequate as an operational document.
>
>     Next steps:
>
>       refine for WG last call, publish as BCP.
>
>
>   - draft-ietf-grow-bgp-wedgies-00.txt
>     Griffin/Huston
>
>
>     Geoff: This draft is ready for WG last call. No further comments on
>         Mailing List. Draft describes BGP state when preferences used.
>         There are circumstances where you can receive traffic on non-
>         preffered link, and only coordinated action across multiple ASs can
>         flip the BGP state back to its intended state.
>
>     WG Comments:
>
>        Pekka:  commented 1/2 year ago. comments recorded/addressed?
>
>        Geoff:  will do at last call.
>
>   - draft-ietf-grow-rift-01.txt
>     Meyer
>
>     Dave:   No work, will address
>
>
> o Tunnel end-point discovery using anycast 10 minutes
>   draft-palet-v6ops-tun-auto-disc-03.txt
>   Savola
>
>     Pekka : tunnel config bof, looked at way to discover 6/4 tunnel
>       endpoint. The information needs to be NAT viable. May need Well Known
>       Service (WKS)  address for anycast discovery one-packet to anycast.
>       reply from local unicast, build tunnel. no state
>
>       comparable to rootserver anycast.
>
>       issues:  works. needs good prefix filtering. weak security.
>
>       whats left: WKS address. DNS population.
>
>     WG Comments:
>
>       Kurtis: posted to ML that anycast for forwarding plane discovery is
>         bad idea. untrustable. ISP is clueful enough to filter etc. don't
>         like this.
>
>       Pekka:  only tunnel discovery. not forwarding plane. fix in tunnel
>         establishment
>
>       Geoff:  GROW went through embedded address draft, noting that
>         identifying services by address is really bad idea. manufacturers
>         embedding addresses etc.
>
>         If the objective is attempting to identify generic type of service,
>         then proposing an address that is used to look into service
>         discovery has the same disadvantage as the embedded address
>         critique. Why not do real service discovery? SLP work. i.e.
>         identify a service by name, attributes. I don't understand why you
>         think its better done down a level by a well known unicast address.
>         This is the same as 6to4 reverse-DNS issue, where Keith Moore
>         explored 'distinguished address' and discounted as weak approach.
>         Not sure you have added it here.
>
>       Pekka:  fundamental difference embedding addresses in RFCs for
>         unicast purposes. this is WKS anycast address. does not belong in
>         any operators prefix. outside of unicast allocation space.
>
>       Dave:   suppose scheme came into reality. how large prefix needed?
>         scalable? eg /16 for protocol. [pekka /24 ok] not globally
>         routed? [pekka same as 6to4 endpoint anycast] -so its meant
>         to be within service provider only.
>
>       Joe:    consider non-routable prefix deliberately to avoid hijacking.
>
>     No WG action proposed
>
> o Preliminary measurement results on the current AS level topology
>   Zhang/Massey 30 minutes
>
>   Lixia still working on highly active prefixes, but this time looking at
>   AS topology changes. public BGP sources, updates from RouteViews/RIPE,
>   IRR
>
>   Previous models always taking dumps. From ripe or routeviews.
>
>   graphs of new AS, rate of new AS visibility in 2004. graph of visibility
>   of links.
>
>   ranking methodology based on topology map, inferred relationships.
>
>
>  slides of ranking/tier behavior breakdowns for links, new AS, change
>
>   Geoff:  measures that paths seen in updates are 'real' as distinct from
>         BGP explorations during convergeance.
>
>   Lixia:  during slow convergeance, exposes alternate paths, AS links do
>         exist, just should not be used. as opposed to no peering session
>         existing.
>
>   Geoff:  so you assume updates expose reality.
>
>   Lixia:  depends how you define reality. defined as stable path, no.
>         slow convergeance shows backups. but if reality is existence
>         of AS peering, then yes.
>
>   Gengis: agree with Geoff. True growth or apparent?
>
>   Lixia:  do not think this is just transient thing. measured over 3 months
>         accumulated links, nodes over period.
>
>   Gengis: don't quantify here, see all new links, lifetime? eg 2hr
>         transients what if seen twice.
>
>   Lixia:  will be considered as existing link. volume of change doesn't
>         count
>
>   Lixia:  not measuring stable links only, used for traffic, measuring all
>         existing links, known links.
>
>   Jeff:   was data corrected for non-bogus AS paths [no]
>
>   Lixia:  additions is in tier2 for links, tier5 for nodes.
>
>   Joe:    inter-domain t-e technique. prepending non-local paths, to poison
>         paths. in your data would imply connectivity not there.
>
>   Lixia:  no filtering for prepends. But we think exceptions to norm
>
>   Impact on BGP operations
>
>      convergence time for lower tier AS is longer than tier-1. during slow
>      lower tiers see customer route changes, tier-1 don't do transit so
>      don't see these, only peer(1) changes.
>
>     denser connectivity increases alternate path visibility. makes slow
>     convergence worse.
>
>   Jeff:   did you see correlation between number of explored paths and
>         convergeance time?
>
>   Lixia:  definitely.
>
>   Still looking at topology impact on convergeance.
>
>
> o A mechanism to enable fast routing table recovery after BGP session reset
>   Nischal Piratla.
>
>   inefficient recovery from transient session resets
>
>   propose bloom filter to encode routing table. exchange digests
>
>   compact size, low b/w cost to share. low false positive rate
>
>   false positives can be filtered by hash functions in digests. 0.003% left
>
>   pekka:  trading off b/w for processing cost. compute matches cost against
>         sending the BGP
>
>   tony:   what do you see as the constraint on convergeance?
>
>   nischal: table sending time. time to reach convergeance is long
>
>   tony:   time for convergeance has interesting things, its more than
>         the bit size on the wire. time is dominated by processing not
>         transfer of data. this minimizes b/w. inconsistency detected
>         is only the presence of routes. even with exchanged hash,
>         but path attributes may need to be exchanged. eg session reset
>         then requires the full set of updates anyway. they will all
>         disagree
>
>   lixia:  digest is not calculated on every update. more periodic. do
>         not have to instantly re-calc. secondly, after session reset
>         try to avoid huge prefix swap, by just examining which entries
>         have changed, only exchange updates as incrementals
>
>   tony:   BGP already does incremental updates. don't understand where
>         this is going.
>
>   joe:    confused as to the goals. few routes different, session gets
>         reset and entire table is sent. this model has to do almost
>         the same amount of work apparently
>
>   nischal: not entire entry, just prefix
>
>   Chandra: think issue here is that even one blackhole route is not good.
>         fixing false positives is good, but if has known error rate
>
>   Jeff:   even if have perfect way to keep tables in sync, session reset
>         will require invalidation, regardless of overhead, processing
>         etc cost is significantly less than route selection on entries.
>
>   Vila:   exchange network b/w for router memory. use graceful restart
>         doesn't matter how long takes, traffic flows. whats the point
>
>   Jeff:   doesn't preserve forwarding table
>
>   YaKov:  why use graceful restart. flaps. spend bit more effort trying
>         to reduce BGP flood, help other things anyway
>
>   Tony:   cannot stop the backhoe. using this to schedule updates is good,
>         accelerate convergeance, schedule deltas ahead of full table
>         but still have to send full table. simpler mechanism for all
>         of this. put the work on sender side with its incremental updates
>         using re-sync procedure, schedules, floods first, then trickle
>         older updates later. can do that no problem.
>
>         This is a wonderful technique, but it is more applicable to ISIS,
>
>   Henk  calc/processing overhead. measured? against eg stable situation
>         adding one route inconsistency, measure time, effort compared
>         to classical?
>
>   Nischal do normal BGP costs more: digest exchange costs max 760k, full
>         table costs 5+Mb.
>
>   Chandra status? intention?
>
>   Nischal grow, or other places, have to sit and decide.
>
>   Dave    not appropriate for operations group
>
>
>
> o BGP Status Reports 10 minutes
>   Huston
>
>   Dave:   how many more specifics relate to rational strategy (TE) as
>         opposed to badness.
>
>   Geoff:  tracking that.
>
>   Yakov:  AS runout or IPs first?
>
>   Geoff:  AS by about 2 years.
>
>   more instability coming because of convergeance on AS paths M&A, more
>   tier3/4 coming up the food chain
>
>   V6 routing, flat BGP announce, 2x covered address space. 500 participants
>
>   still overlay network (only 9 v6 only instances, no transit)
>
>   10% aggregation possibility
>
>
> web archive:        http://darkwing.uoregon.edu/~llynch/grow/

_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/