Re: [OSPF] TTZ, my 2c

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

Return-Path: <prz@mail.zeta2.ch>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45F511E817F for <ospf@ietfa.amsl.com>; Tue, 9 Jul 2013 14:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUscuO3y3H1c for <ospf@ietfa.amsl.com>; Tue, 9 Jul 2013 14:42:08 -0700 (PDT)
Received: from www.zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id 0332721F9B10 for <ospf@ietf.org>; Tue, 9 Jul 2013 14:42:02 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id r69Lg0id001027 for <ospf@ietf.org>; Tue, 9 Jul 2013 23:42:00 +0200
X-Virus-Scanned: amavisd-new at zeta2.ch
Received: from www.zeta2.ch ([127.0.0.1]) by localhost (www.zeta2.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id D4yPuG2Pe05U for <ospf@ietf.org>; Tue, 9 Jul 2013 23:41:58 +0200 (CEST)
Received: from [192.168.5.240] (ip-64-134-223-18.public.wayport.net [64.134.223.18]) (authenticated bits=0) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id r69Lfe6b001021 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <ospf@ietf.org>; Tue, 9 Jul 2013 23:41:53 +0200
Message-ID: <51DC8395.5060703@zeta2.ch>
Date: Tue, 09 Jul 2013 16:41:41 -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@ietf.org
References: <51DC4844.7050106@zeta2.ch> <5316A0AB3C851246A7CA5758973207D4451E2F4C@dfweml509-mbx.china.huawei.com>
In-Reply-To: <5316A0AB3C851246A7CA5758973207D4451E2F4C@dfweml509-mbx.china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [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 21:42:14 -0000

Am 09.07.2013 15:53, schrieb Huaimo Chen:
> Hi Tony,
>
>      Thanks for your comments!
>      See my responses inline below.
>
> Best Regards,
> Huaimo
> -----Original Message-----
> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of A. Przygienda
> Sent: Tuesday, July 09, 2013 1:29 PM
> To: 'OSPF List'
> Subject: [OSPF] TTZ, my 2c
>
> 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
>
>
> draft-chen-ospf-ttz-app-03.txt
>
> 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)
>
> [Huaimo] The reason for comparing a network having one area with the one having 10 TTZ is that the latter has some attributes of one area. The network having 10 areas does not have these attributes.
pls be more specific here. Area will summarize 1/10 of the routers into 
ideally one prefix which is actually much smaller than a full mesh of 
TTZ routers (ad extremis). I think a fair comparison should address all 
this.
> 2. Section 5.2.2.2 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'
> drafts.
>
> [Huaimo] Can we focus on LSP setup first?  For LSP setup, do you see any issue in this section? For LSP protections, we can propose some solutions later.
Yes, an example of LSP setup including label distribution (without /32s 
??? in TTZ )  would be nice.
>
> 3. 5.2.2.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.
>
> [Huaimo] loopback address distribution will be addressed.
ok
>
> 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 ?
>
> [Huaimo] This will be considered.
ok
>
>
> draft-chen-ospf-ttz-05.txt
>
>
> 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)
>
> [Huaimo] This will be addressed.
ok
>
> . 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
> area.
>
> [Huaimo] At first, we limited a TTZ in one area. You are right. Some checks need to be done for this.
ok
>
> . 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.
>
> [Huaimo] The number of edge nodes of a TTZ should be small.
_should_ be small is not sufficient normally for a working protocol in 
the wild. I fail to
see how you want to guarantee that if someone simply connects a router 
in the area
to a TTZ router in the same area. They will form an adjacency by 
default, right ? So you
don't even have something like area-id protection to not form 
adjancencies on
misconfigurations (as in 'tons-of-TTZ' routers accidental misconfig)
>
> . 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.
>
> [Huaimo] Can you give more details about this?
well, if you start to slosh 160 /32's out the area, pretty soon you wil 
be tempted
to summarize as well (as in OSPF standard area).  Then you run into 
type  5-7 problems
(as OSPF area summaries do) and you'll have to re-invent or re-use all 
those mechanisms
again.
>
> 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 ?
>
> [Huaimo] Full mesh connections of the edges is one type of connections of the edges. The above sentence indicates that a TTZ may have a type of connections including full mesh.
Then this will become nothing else but 'abstract node representation' in 
PNNI you're re-inventing
here then (hub-spokes, weighted centers of graphs, tangentail shortcuts 
& all the other
animals of the zoo). This was a famour rathole I suggest to revisit 
despite ATM not being the
hottest technology (anymore ;-))
>
> 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.
>
> [Huaimo] Configuring a TTZ will be simpler than configuring an area. We are working on it.
> The behavior should also be simpler.
as I said and it's original jest of my mail, after you're done with all 
the problems, I would be highly
surprised if this proves the case.  But that just my personal rusty 2c

Sorry to be tough but tough love is best love for internet drafts often '-)

-- tony