Subject: RE: My Thoughts on Site-Locals

From: "Michel Py" <[email-masked]>
Date: Fri, 4 Apr 2003 08:34:06 -0800

Alex,

> Alex Zinin wrote:
> The problem or rather inconvenience with tieing site
> boundaries and area/domain boundaries is that they
> are driven by different factors. Imagine, for instance,
> that your site that is currently implemented as an OSPF
> area is growing so big that you need to split it into
> multiple areas to give your routers a break. Because
> your site boundaries are driven by non-routing
> considerations (you just want your network to continue
> working as it used to), you don't want to split the site
> into two, so what you end up with is removing that big
> site from the OSPF domain in a separate one and splitting
> it into its own areas, while normally you would just have
> one more area in the OSPF domain. Operationally, this
> might be a headache.

Agreed. I don't like the word "area" myself in this context; I was
simply quoting Margaret's words. There are plenty of other cases like
this, for example using two different IGPs as the result of a
merger-never-finished-the-cleanup or related; I have seen a site where
half of it was EIGRP the other half OSPF with mutual bidirectional
redistribution and eBGP in the middle. :-(
Mmmm thinking about it, :-) job security.

Anyway, I suggested earlier that the site boundaries should be the
administrative control boundaries of the organization. It might not be
the correct wording, but my feeling is that we could come with some text
that will detail the position of site boundaries.

I have made the point earlier many times that the definition of "site"
is ambiguous and/or imprecise, there is some geographical connotation
attached to the word, we need a good definition anyway.

>> This is the way I would do it anyway. I understand that we
>> should not put restrictions when there is no need for them,
>> but if putting a restriction allows something to work there
>> is nothing wrong with it.

> I don't think this is _the_ problem. This only contributes
> to the list of complications. Also count modifications to
> RIB, FIB management, the forwarding process, making pings,
> traceroutes, etc site-aware... It's not impossible, in fact
> we know exactly how to do this, it just that complexity adds
> up to one side of the equation, and you really want to avoid
> extra complexity in routing and below...

I agree, but the other side of this coin is that if the feature is not
implemented in the architecture it will be implemented by the
configuration at the site. In other words, if as a site administrator I
am not happy about the way the site-local traffic flows I am going to
tweak it using route-maps, prefix-lists, route tags and whatever I feel
like doing for my intra-site traffic engineering. Each site will end up
being configured differently. Although there still is a lot of work to
be done on the topic, I think that the convexity of the site is a good
idea to incorporate in the architecture.

In short:

- If site convexity is not built-in the architecture, it might or might
not work depending on implementation, network topology, etc. This will
lead in many cases to manual policy routing config to make it work the
may it should.
- If site convexity is built-in the architecture, the only case where it
would require manual policy routing config is if the site administrator
wants to break convexity. I can't think of a reason but I'm sure they
are some valid ones.

As some others have commented, IPv6 is not only IPv4 with more bits. The
issue of "automatic site convexity" is definitively a pain to implement
in router code, but is also a feature that simplifies the life of
network administrators and as such a factor of success for IPv6.

Michel.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Alex Zinin <[email-masked]>
Date: Fri, 4 Apr 2003 21:38:48 -0800

Michel,

> simply quoting Margaret's words.

Well, it's not that I don't like the word "area" here, in fact it
would not be unreasonable to assume that people would want to map
sites to areas...

> There are plenty of other cases like

Sounds really bad. Mutual redistribution is a very risky thing, but
if done properly does not need eBGP... anyways, it's a mess and we
don't want the architecture to encourage this...

> attached to the word, we need a good definition anyway.

I don't think a "better" definition is going to help here. No matter
what we say a site should be, the day people start deploying them
we'll hear back from the customers smiling at the definition and
giving us their reasons why they have to ignore it (e.g. my
organization has just become a department within a bigger one, what
should I consider a site now?)

Again, there is a disconnect between the driving factors defining
site boundaries and those defining routing hierarchy elements.

> idea to incorporate in the architecture.

I think there might be some confusion here.

Even if site support was introduced into routing, SL topology and
global one would be congruent (making them non-congruent would be too
much complexity), which means that the path taken by packets that
belong to a connection within a site would be the same regardless of
whether SL or public addresses are used. So, SL do not add anything
here at all.

> wants to break convexity. I can't think of a reason but I'm sure they

If you are interested in convexity as a feature (rather than a
requirement to make SLs work), we already have a similar notion in
routing, but it is applied to areas and AS'es--for example, OSPF area
are logically convex, i.e., traffic between hosts within the same area
will be contained within the area because routers prefer intra-area
routes over inter-area ones. You don't need the notion of sites here.

> network administrators and as such a factor of success for IPv6.

I guess we disagree on the "simplifies" part here :)

Alex