Re: [OSPF] TTZ, my 2c

Huaimo Chen <huaimo.chen@huawei.com> Tue, 09 July 2013 21:51 UTC

Return-Path: <huaimo.chen@huawei.com>
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 8329421F9B9F for <ospf@ietfa.amsl.com>; Tue, 9 Jul 2013 14:51:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
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 DJeuXR2Ua+QV for <ospf@ietfa.amsl.com>; Tue, 9 Jul 2013 14:51:52 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 75A8E11E8164 for <ospf@ietf.org>; Tue, 9 Jul 2013 14:51:47 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUV35821; Tue, 09 Jul 2013 21:51:44 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 9 Jul 2013 22:51:11 +0100
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 9 Jul 2013 22:51:26 +0100
Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Tue, 9 Jul 2013 14:51:23 -0700
From: Huaimo Chen <huaimo.chen@huawei.com>
To: Acee Lindem <acee.lindem@ericsson.com>, OSPF List <ospf@ietf.org>
Thread-Topic: [OSPF] TTZ, my 2c
Thread-Index: AQHOfMnSFayg2jpL40ykNrJFdj5x45ldJkGA//+wT0A=
Date: Tue, 9 Jul 2013 21:51:23 +0000
Message-ID: <5316A0AB3C851246A7CA5758973207D4451E2FA0@dfweml509-mbx.china.huawei.com>
References: <51DC4844.7050106@zeta2.ch> <94A203EA12AECE4BA92D42DBFFE0AE4719D4CE@eusaamb101.ericsson.se>
In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4719D4CE@eusaamb101.ericsson.se>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.245.66]
Content-Type: multipart/mixed; boundary="_002_5316A0AB3C851246A7CA5758973207D4451E2FA0dfweml509mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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:51:53 -0000

Hi Acee,

    Thanks much for your comments!
    My responses are inline below.

Best Regards,
Huaimo
-----Original Message-----
From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem
Sent: Tuesday, July 09, 2013 2:51 PM
To: OSPF List
Subject: Re: [OSPF] TTZ, my 2c

Speaking as a WG Member:

I don't think this draft lives up to its claims. I agree that the 1600 flat OSPF example is bogus. Not only due to the network topology but due to the application of TTZ. The example assumes NO outside connectivity to the internal TTZ routers which begs the question of why these were ever connected in the first place. This would imply the 154 internal TTZ routers exist solely to interconnect the 6 TTZ border routers. I don't think anyone believes this.

[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.
The outside access to the internal TTZ will be addressed.


Given that any reasonable example requires TTZ internal routes to be advertised outside the TTZ, there needs to be some policy to determine what is and what is not advertised outside the TTZ. Given this requirement, the argument that it is simpler to configure than OSPF areas is false as well. 

[Huaimo] Do we need some policy on an ABR to determine what is and what is not advertised from a backbone area to a non-backbone area? If so, TTZ is easier because there is need for this kind of policies.


Once you start advertising internal routes in the TTZ border Router-LSAs, you multiply each route by the number of TTZ border routers. Also, you are now trading off more smaller LSAs for fewer larger LSAs that change more rapidly especially in situations where the network is first coming up. I can you tell from years of implementation experience that this is not a good trade-off. Depending on the topology, internal routes advertised, and pattern of network changes, this solution will actually have WORSE scaling characteristics than without TTZ. Keep in mind that changes in TTZ internal topology will also manifest themselves as change in the TTZ border router full links.

[Huaimo] We may discuss this in details.


Like Hannes, I'm also interested in how this makes TE easier?

[Huaimo] Let focus on an LSP crossing multiple TTZ vs multiple areas first.
In multiple areas case:
We may need help from PCE. A TE path crossing multiple areas is computed by using collaborating Path Computation Elements (PCEs) [RFC5441] through the PCE Communication Protocol (PCEP)[RFC5440], which is not easy to configure by operators since the manual configuration of the sequence of domains is required.  Although this issue can be addressed by using the Hierarchical PCE, this solution may further increase the complexity of network design.
In multiple TTZs case:
We do not need any help from PCE. In addition, the LSP crossing TTZs is set up in a usual way. See the slide attached. 


In summary, I'm not against looking at use cases as Russ and Alvaro proposed. However, I'm not convinced TTZ buys you any advantage in any use case. 

[Huaimo] The advantages of TTZ include:
1) It makes TE easier. When we use TTZs instead areas, TE LSPs crossing multiple TTZs are set up in a usual way. With multiple areas, either PCEs are used or some complex configurations are needed.
2) Dividing a network having a backbone area into the one having multiple areas is very hard. There was a real network having a area with 1000+ nodes. A team from the vendor and the operator spent about one year in splitting it into multiple area. Dividing the network having one area into the one having multiple TTZs is much easier. It may take a team for a much less time. I presented this in the last IETF.
3) Configuring a TTZ may be simpler than configuring an area.


Thanks,
Acee 

On 7/9/13 10:28 AM, "A. Przygienda" <prz@mail.zeta2.ch> wrote:

>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)
>
>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.
>
>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.
>
>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 ?
>
>
>
>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) . 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.
>. 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
>
>
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www.ietf.org/mailman/listinfo/ospf

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf