Minutes for GROW at IETF-91
minutes-91-grow-1

Monday November 10, 2014 17:30 session

Draft status.

Ilijitsch van Beijnum
Controlled ipv6 deaggragation by large providers.
Size of the routing table growing pretty consistently year over year - 4k.
More specifics are growing at a faster rate.
Examples…
top level /32, plus many /48’s.
Network from Korean government

What is this:
traditionally provider aggregatable (PA) - used by ISPs or Provider
Independent (PI) - used by users.
Large organizations find it useful to have one big PA-like prefix
However, offices connect via different ISPs (geography, e.g)

Deggregation:
- Big multinationals, governments?
- Become “enterprise LIRs” and objtain a PA prefix
- Subunits deaggregate either toward different ISPs or at different
  locations for traffic engineering purposes.

Is this a problem?
Not today - IPv6 table is still small.
IPv4 has shown us that we will likely have a problem.  Solve the problem
today.

Does this work well for those organizations?
- Mostly.  However, deagg may be filtered.
- Filtering is inconsistent because of lack of best practices

What do we do?
- Nothing?
- Start conversation between enterprise LIRs and network operators; give
  guidance? Give network operators tools to control table size?

The idea:
Allow enterprise LIRs to setup an “aggregate of last resort” (AoLR)
- Place traffic has a place to go if deaggregates are filter
- Tag deaggregates with BGP communities to indicate that it’s safe to
  filter

AoLR:…
(example)

Possibly helpful - encoding location into bgp community to provide
geographic filtering?

Possible suggestion - community that covers general division of the planet.
Possible geo-fencing with this.

Why not extended community?  We’d have to wait on vendors.

Selective filtering…

What now?
RIPE BCOP interested in the best practice part
Definiing communities needs to happen in an RFC - perhaps as part of a
document defining other new well-known communities?

Questions?
Rudiger Volk, Deutsche Telecom…
Claim is getting address blocks is expensive?  In what region?
This looks complex.
What advice is given? What advice is being given that tells people how to
deploy their address space?  Good use?

IvB: do you want me to tell you if I think this is a good idea?

RV: It’s an interesting question whether it’s going to help people,
and the world, to give them a document that provides a complex mechanism.
Different structures might be adequate.

IvB: I.e. why shouldn’t we use best PA practices?

RV: For the German state dept. example, if they want to operate an embassy,
whose address space do you use?  DT? Local?

IvB: Reason to use independent prefix, main reasons is multi-homed or
firewall filters.  Life is easier if not.  There seems to be evidence that
they value recognizable address space or are multihomed.

RV: Not sure if multi-homed is an interesting case in majority of cases.
Can see they want Provider independence.  The address structures that are
avaialble in IPv6 provide easy ways to move.

IvB: You said the same things in London.  Other people?

Cath Aronseny: Geographic addressing has *never* worked.  This is just
another layer - it’s not going to work.
If you have a PA, you can announce more specific.  It’s okay for the
more specific to be filtered because the aggregate will still get you there.

IvB: Actually geo addressing has never been tried.

CA: It’s topological, not geographical.

Joel Jaeggli: I have these anycast addresses. There are covering aggregates.
Topology discovery should guide how they are used, not the geographical
filters.

IvB: Topology isn’t geography, but if you don’t hook up in things
that are close enough… If you step away far enough…

JJ: You put some things that are in the same region that aren’t
close…

Chris Morrow: Sounds like I’s proposal is to educate customers on better
ways to connect to network when offices need to connect for many sizes.

JJ: Enterprises have many sizes.  Solutions may be different depending on
size.

CM: The point I is trying to get to, is providing guidance - is that
something grow should do?  The specifics in the draft can come later.

IvB: 15 years ago, ran a Dutch ISP, two upstreams.  Made filters to make
sure to choose things that didn’t cross circuits are far away.

Jen L? Geography may be very different than topology.  Looking at the
latency.  Having trouble understanding how this is different from ipv4? If
we’re going to create BCP, consider do you really need to advertise more
specifics?  If so, consider location.  Will likely be similar to ipv4.

IvB: Difference is that the block is large and thus you *can* aggregate.

[mic cutoff]

——

Sriram K. NIST
Definitionand Classification of Route Leaks.

Got a lot of feedback from the Toronto session.

Diffs:
- Separated the problem and solution draft.
- Added a working definition of route leaks
- Added type 5 - lateral ISP to ISP leak
- Included accidental deaggregation
- Some additional examples.

[slide covering basic notion of route leaks]

New working definition. Heavily focused on “intent”.
Please review and comment.

Anatomy of route leaks: Classification.
[various slides on definitions - see meeting materials]

Should this draft be adopted?

Andrei Robachevsky:  These are just different cases of valley free?

SK: If you look at these things in the context of SIDR, if you classify it
according to this kind of slicing, we might have solutions in an
rpki-context.  Look at the problem/definition, if the definition is useful
we can do that down the road.  It helps puts things in perspective.

AR: It’s not fully redundant.  Lateral doesn’t different much from
multi-homed customer.

SK: When you start paying attention to the details, they are different kinds
of hijacking, with different levels of success.  E.g. pass ROA validation.

Dan York: It was useful to see these slides.

Brian Dickson: Valley free, there are examples that are shown to be valley
free but are route leaks.  Customer sent to route but sent to customer’s
peer is still valley free but a route-leak.

Geoff Huston: Concept that valley free encompasses everything is off the
mark.  assumes there’s a consistent route policy for SPs.  Different is
normal.  Assumes you can infer relationship from a distant - you can’t.
In Lixia’s paper, they tried and it didn’t work - didn’t
classify.  What you’re saying here, here are things that leak outside of
*intent*.  Leak that creates different outcomes in forwarding are the ones
that matter.

Poll of room: adopting.  all hands  in favor. none didn’t.

——

Chris Morrow:
Robert from RIPE NCC
Draft in SIDR working group (?) that could use review in grow due to
knowledge in RPSL?  Will resurrect and bounce off grow.et involved with
Etherpad at http://etherpad.org