[OSPF] TTZ, my 2c

"A. Przygienda" <prz@mail.zeta2.ch> Tue, 09 July 2013 17:28 UTC

Return-Path: <prz@mail.zeta2.ch>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C6C1B21F9E05 for <ospf@ietfa.amsl.com>; Tue, 9 Jul 2013 10:28:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cG0e949QO5FL for <ospf@ietfa.amsl.com>; Tue, 9 Jul 2013 10:28:51 -0700 (PDT)
Received: from www.zeta2.ch (zux172-086.adsl.green.ch []) by ietfa.amsl.com (Postfix) with ESMTP id 946B621F9F27 for <ospf@ietf.org>; Tue, 9 Jul 2013 10:28:47 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id r69HSihV024383 for <ospf@ietf.org>; Tue, 9 Jul 2013 19:28:44 +0200
X-Virus-Scanned: amavisd-new at zeta2.ch
Received: from www.zeta2.ch ([]) by localhost (www.zeta2.ch []) (amavisd-new, port 10024) with LMTP id 1QRxdQblM2wD for <ospf@ietf.org>; Tue, 9 Jul 2013 19:28:43 +0200 (CEST)
Received: from [] (ip-64-134-223-18.public.wayport.net []) (authenticated bits=0) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id r69HSZGR024378 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <ospf@ietf.org>; Tue, 9 Jul 2013 19:28:39 +0200
Message-ID: <51DC4844.7050106@zeta2.ch>
Date: Tue, 09 Jul 2013 12:28:36 -0500
From: "A. Przygienda" <prz@mail.zeta2.ch>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: "'OSPF List'" <ospf@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [OSPF] TTZ, my 2c
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2013 17:28:56 -0000

Somehow the list killed my email. Another attempt. Kind of agree with 
Hannes I guess

So, looking at other stuff zipped over the TTZ drafts and it's an 
intriguing idea but IMHO suffers from
several heavy defects. Quick incomplete list


1. Section 5.1 is bogus. A reasonable scalability comparison  should not 
be between 1600 Rs flat OSPF and
     10 TTZs but between  10 areas & 10 TTZs (which will come by my gut 
feeling to about the same or rather
     small difference)

2. Section is probably misleading. The example completely skirts 
the issue how a tunnel  can be
    computed not only through the TTZ border routers but through 
internals of TTZ. I assume that happends
     by the 'virtual links' and that leads to good amount of problems by 
itself since there is the need to setup
     labels within the TTZ, issues with link- and node-disjointness in 
case of protections and similiar nit-picks.
     All those issues are probably similar to the new 'segment-routing' 

3. basically assumes that there is no reachability needed within 
the TTZ (i.e. prefixes). Yes, then ABR
     summaries are not needed but how do you manage something like the 
routers in TTZ (loopback addresses of the routers) ?
     It's one thing to intentionally hide-the-transits and another to 
not have a possibility to reach the routers.

4. I see how section 5.5 (POP) or 5.7 will work. That maybe a possible 
application and simpler than NSSA. However,
     customer prefixes must bubble up somehow unless they are configured 
only on a single TTZ pointing towards \
     core ?


In general, all the claims to 'simpler than area' seem to me based on 
the fact that

a) all the things that an area needs are ignored here
. no indication what happens on partitioning of TTZs(should be simple)
. no indication what happens when TTZs find themselves in 2 different 
areas ? Do the TTZ borders start to act like
border routers ? Saying 'they MUST not' is IMHO not good enough for 
deployable protocol, mode of failure
must be described & debugging procedure. Best would be e.g. if TTZ 
borders check for Area ID on router LSAs
(which would need to be carried in a new opaque or something like this 
?) and make sure TTZ is in a single
. I assume that routing integrity (hop-by-hop) is guaranteed, by 
external routers computing
'routes using the "virtual TTZ links"'. This IMHO will be a major 
scalability problem (and routing loops)
once the TTZs grow since the number of virtual links grows about N^2/2 
of edges. This will quickly lead
to TONS of virtual links which will need to be distributed & lead to 
transit routing loops since those
'virtual links' are topology summaries and will not reflect the 'real 
topology', i.e to make sure you don't
have routing loops the TTZ border routers can only use the tunnels when 
they have been redistribugted to
everyone i.e. after everyone has the same topology (how you do that?). 
Otherwise they must use the 'previous' topology before
the summarization into virtualk links. Yes, those are transient loops 
but having 10 TTZ borders will generate already
50 tunnel summaries and they take time to distribute.
. no indication how internal reachability within TTZ is guaranteed & 
summarized and how it is guaranteed that e.g.
prefixes are not being reimported as type 5 or 7 into the TTZ again 
through backdoor mechanisms (e.g. TTz
borders in two different areas) in case
TTZ ends up summarizing.

b) I don't understand 8.3. What is "a TTZ is virtualized as a group of 
edge routers of the TTZ connected". Section 7 implies that TTZ edges are 
advertised as full mesh of 'virtualized links'. Contradiction ?

So, my gut feeling is after everything has been solved this will be more 
complex or equal to areas in terms of configuration,
behavior, contraints for a questionable gain of having a full-mesh-TTZ 
construct versus a prefix-summary ABR construct.

And it suffers from couple issues I pointed out above which would have 
to be addressed before anything like this
is deployed in the wild ;-)

--- tony