Subject: Fwd: Re: My Thoughts on Site-Locals

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

Folks-

 For those of you not following the ipv6 WG, they are now verifying
 the consensus to remove SLs that was reached in SF. Feel free to
 chime in and inject some routing clue there.
 
-- 
Alex

This is a forwarded message
From: Alex Zinin <[email-masked]>
To: "Michel Py" <[email-masked]>
Cc: "Margaret Wasserman" <[email-masked]>, [email-masked]
Date: Friday, April 4, 2003, 9:38:48 PM
Subject: My Thoughts on Site-Locals

===8<==============Original message text===============
Michel,

> Agreed. I don't like the word "area" myself in this context; I was
> 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
> 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.

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...

> 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.

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.

> 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.

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.

> 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.

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.

> 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.

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

Alex

--------------------------------------------------------------------
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]
--------------------------------------------------------------------

===8<===========End of original message text===========

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 05 Apr 2003 23:56:05 +0200

> chime in and inject some routing clue there.

good work, sense prevails (for once)

    --- tony