Subject: grow: draft minutes for IETF 62

From: David Meyer <[email-masked]>
Date: Thu, 17 Mar 2005 13:33:57 -0800

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Mar 2005 23:56:26 +0200 (EET)

Joe, others,

I'll follow up with this one, because there was no longer room for 
discussion, inline..

>  draft-palet-v6ops-tun-auto-disc-03.txt
[...]
>      Joe:    consider non-routable prefix deliberately to avoid hijacking.

Yes, a non-routable prefix would precisely fulfill our goals, and we 
have considered it.

Unfortunately, the consideration reached a dead end.  The only 
inherently non-routable (by some definition at least, the reality 
differs) prefix would be from RFC1918 space.  But that would collide 
with some poor sucker behind a NAT using that address space, or an ISP 
using that address space.. so it isn't really a good solution.

So -- do you have any specific ideas where one could possibly carve 
such a non-routable prefix?  If you (or someone else) has any ideas, 
I'd be delighted to hear them..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/

---

From: Joe Abley <[email-masked]>
Date: Thu, 17 Mar 2005 17:39:48 -0500

> using that address space.. so it isn't really a good solution.

Specifying a 1918-reserved address would be in conflict with RFC1918, I 
think, since you intend for external sites (customers) to use it.

What it sounds like you're looking for is a route which is commonly 
excluded by ingress martian filters in ISPs. There are non-RFC1918 
examples to be found in RFC3330 (although there are probably individual 
reasons for not choosing addresses from there). Alternatively, any host 
route (or any prefix longer than 24 bits) is unlikely to propagate far 
(if at all) across the production Internet, unless special arrangements 
have been made (e.g. between providers and customers).

I wish the phrase "non-routable" in relation to RFC1918 would 
disappear, incidentally. The restriction is that the addresses be used 
within a single site, not that packets with them never traverse a 
router.

Joe

---

From: Geoff Huston <[email-masked]>
Date: Fri, 18 Mar 2005 09:38:50 +1100

Hi,

I would still claim that the service location protocol is the tool of 
choice for this application. What precisely are the impediments to use of 
SLP in this context?

   Geoff

At 08:56 AM 18/03/2005, Pekka Savola wrote:
>Yes, a non-routable prefix would precisely fulfill our goals, and we have 
>considered it.
>
>Unfortunately, the consideration reached a dead end.  The only inherently 
>non-routable (by some definition at least, the reality differs) prefix 
>would be from RFC1918 space.  But that would collide with some poor sucker 
>behind a NAT using that address space, or an ISP using that address 
>space.. so it isn't really a good solution.
>
>So -- do you have any specific ideas where one could possibly carve such a 
>non-routable prefix?  If you (or someone else) has any ideas, I'd be 
>delighted to hear them..
>
>--

---

From: Pekka Savola <[email-masked]>
Date: Fri, 18 Mar 2005 10:38:56 +0200 (EET)

On Fri, 18 Mar 2005, Geoff Huston wrote:
> I would still claim that the service location protocol is the tool of choice 
> for this application. What precisely are the impediments to use of SLP in 
> this context?

From the draft,

3.5  SLP-based Solutions

    The Service Location Protocol [12] provides a framework for the
    discovery and selection of network services.  Tunnel-End-Point for
    IPv6 tunnels could be defined as a network service which will have
    also assigned a specific service name.

    SLP has a number of drawbacks:

    o  SLP is not really widely implemented or deployed.

    o  It requires multicast infrastructure or the additional deployment
       of Directory Agents (DA) for Service Agent (SA) discovery.

    o  If DA is deployed and the network has not multicast support, some
       way for discovery the DA is required.  DHCP could be used [12] but
       this has the same issues why a DHCP-based approach is not
       sufficient (in Section 3.3).

    o  It requires the implementation of a User Agent (UA) on the
       client's host.  This is neither always possible nor feasible.

    o  It can not offer any kind of load-balancing if more than one TEP
       is deployed.

    In short, SLP seems to come awfully short in matching the
    requirements for the solution.

.. in short, even if SLP was typically and commonly used (and it isn't 
:), we'd still need a mechanism to discover SLP DA, and we'd be back 
at square one.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 18 Mar 2005 10:40:42 +0200 (EET)

On Thu, 17 Mar 2005, Joe Abley wrote:
>> behind a NAT using that address space, or an ISP using that address space.. 
>> so it isn't really a good solution.
>
> What it sounds like you're looking for is a route which is commonly excluded 
> by ingress martian filters in ISPs. There are non-RFC1918 examples to be 
> found in RFC3330 (although there are probably individual reasons for not 
> choosing addresses from there). Alternatively, any host route (or any prefix 
> longer than 24 bits) is unlikely to propagate far (if at all) across the 
> production Internet, unless special arrangements have been made (e.g. between 
> providers and customers).

Thanks -- this is a good point.  Maybe we would just need to reserve 
the host address and some of the issues would go away :)

Kurtis, would that satisfy your security concerns?

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 24 Mar 2005 12:29:49 +0100

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

Tom Petch

---

From: David Meyer <[email-masked]>
Date: Thu, 24 Mar 2005 07:51:33 -0800

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

	Will update if possible. BTW, Geoff has collected all of
	the presentations for the proceedings, so they will also
	be available there.

	Dave

---

From: Geoff Huston <[email-masked]>
Date: Fri, 25 Mar 2005 07:27:52 +1100

Tom

I submitted an html version of the proceedings editor and the presentations 
will be referenced in the minutes. The presentations will of course be 
published in the proceedings.

Geoff