Re: [OSPF] TTZ, my 2c

[Huaimo Chen <[e-mail]>]

Hi Tony,

    Thanks for your comments!
    See my responses inline below.

Best Regards,
Huaimo
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 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.

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.

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. 

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.


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.

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

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

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

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.

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.

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
[e-mail]
https://www.ietf.org/mailman/listinfo/ospf