Subject: [OSPF] OSPF Topology Transparent Zone (TTZ) Next Steps

From: Acee Lindem <[email-masked]>
Date: Sat, 6 Jul 2013 19:09:04 +0000

As WG chair, I'd like to initiate a discussion on this technology. We've had it presented at the last couple IETFs and there are varying opinions on its usefulness. 
For reference:

  Base Document: http://www.ietf.org/id/draft-chen-ospf-ttz-05.txt
  Applicability: http://www.ietf.org/id/draft-chen-ospf-ttz-app-03.txt

Thanks,
Acee

---

From: "Russ White" <[email-masked]>
Date: Sat, 6 Jul 2013 16:28:38 -0400

> As WG chair, I'd like to initiate a discussion on this technology. We've
had it
> presented at the last couple IETFs and there are varying opinions on its
> usefulness.

In general, I think this is useful. I can think of specific situations where
it would be nice/would have been nice to have. In fact, a few of us went
some ways towards designing just such a system (using different mechanisms)
when we were deep into the MANET/OSPF space, but never released,
implemented, etc., the idea.

I would put my vote into making this a WG doc and moving it forward.

:-)

Russ

---

From: William McCall <[email-masked]>
Date: Sat, 06 Jul 2013 16:51:08 -0500

Seems like, to me, the net accomplishment is to avoid a L2VPN layer 
sitting where the internal TTZ nodes are, based on the scenarios 
proposed in these drafts. Looks like it would also allow a lot more 
flexibility in adding nodes to the TTZ vs. trying to do L2VPNs, 
particularly with regard to metric calculation (but also future growth 
if an internal node is made edge).

 From draft-chen-ospf-ttz-05:
>   A TTZ MUST hide the information inside the TTZ from the outside.  It
>     MUST NOT directly distribute any internal information about the TTZ
>     to a router outside of the TTZ.

One thing I'm not so happy about in the drafts is that they seem to 
imply that ANYTHING from the internal TTZ nodes is not sent to the 
TTZ-external nodes from an OSPF perspective. IMO, I'd want the option to 
advertise a loopback (or whatever) from the internal TTZ nodes out to 
the TTZ-external nodes so I can reach them for management, etc. I guess 
this could be done with BGP, but that seems overkill for what I'm 
looking for.

On 07/06/2013 03:28 PM, Russ White wrote:
> In general, I think this is useful. I can think of specific situations 
> where it would be nice/would have been nice to have. 
My opinion would be to adopt it as a WG draft, but with a bit of 
scrutiny as to the use cases. Russ got it right when he said there are 
"specific situations", but I guess the question would be around whether 
the situations are prolific enough to warrant work on this. I vote 
"probably", but smarter people than me know better.

--wm

---

From: Huaimo Chen <[email-masked]>
Date: Sat, 6 Jul 2013 23:43:50 +0000

Hi William,

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

Best Regards,
Huaimo
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of William McCall
Sent: Saturday, July 06, 2013 5:51 PM
To: Russ White
Cc: 'OSPF List'
Subject: Re: [OSPF] OSPF Topology Transparent Zone (TTZ) Next Steps

Seems like, to me, the net accomplishment is to avoid a L2VPN layer sitting where the internal TTZ nodes are, based on the scenarios proposed in these drafts. Looks like it would also allow a lot more flexibility in adding nodes to the TTZ vs. trying to do L2VPNs, particularly with regard to metric calculation (but also future growth if an internal node is made edge).

>     to a router outside of the TTZ.

One thing I'm not so happy about in the drafts is that they seem to imply that ANYTHING from the internal TTZ nodes is not sent to the TTZ-external nodes from an OSPF perspective. IMO, I'd want the option to advertise a loopback (or whatever) from the internal TTZ nodes out to the TTZ-external nodes so I can reach them for management, etc. I guess this could be done with BGP, but that seems overkill for what I'm looking for.

[Huaimo] This is very good point. We will consider the option to advertise a loopback from the internal TTZ nodes out to the TTZ-external nodes.

> where it would be nice/would have been nice to have.
My opinion would be to adopt it as a WG draft, but with a bit of scrutiny as to the use cases. Russ got it right when he said there are "specific situations", but I guess the question would be around whether the situations are prolific enough to warrant work on this. I vote "probably", but smarter people than me know better.

[Huaimo] We will work more on the use cases.

--wm
_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: "Russ White" <[email-masked]>
Date: Tue, 9 Jul 2013 12:50:34 -0400

I want to clarify something on this thread...

> In general, I think this is useful. I can think of specific situations
where it
> would be nice/would have been nice to have. In fact, a few of us went some
> ways towards designing just such a system (using different mechanisms)

This part I think is true --I think we need to think about use cases in this
space, and figure out if there are interesting things to do in the OSPF
space to handle those use cases.

> I would put my vote into making this a WG doc and moving it forward.

OTOH, I've looked through these drafts again, and talked to a couple of
other folks about them, and it seems, to me, that we're starting from the
wrong end of the stick. What we seem to have, right now, is a set of
solution drafts, and everyone is thinking of a different set of problems
when they read those solutions (including me --I read this draft and think,
"this would be useful to solve that problem, if only we could make the
overall modifications simpler, and change this over here, and..."). 

What might be useful would be to step back from the solutions draft for a
moment and build a use cases/requirements draft to start from, rather than
working from these solutions drafts specifically.

HTH

Russ

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 9 Jul 2013 16:53:55 +0000

On 7/6/13 5:51 PM, "William McCall" <[email-masked]> wrote:

>...but with a bit of
>the situations are prolific enough to warrant work on this.

[Disclaimer: I'm one of the co-authors on the TTZ draft, so I obviously
think the technology is useful.]

IMHO, having an ID that talks about those use cases would be an important
step forward.  

Right now the applicability draft talks about some (I'm sure there are
more) of the cases where the TTZ can be used..but I'm suggesting something
the other way around: a set of use cases that need to be solved.  Then we
can measure TTZ (or other solutions) against that set of requirements/use
cases.

My 1c.

Alvaro.

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 9 Jul 2013 19:20:34 +0200

scaling a link-state protocols route-calculation path (SPF and RIB-Walk)
to support 1000s of nodes is an already solved problem.
solving it again, (just different this time) is of limited use …

quite contrary - i fail to see how *hiding* information (i.e. nodes and links
along with their TE attributes) does not break some of the TE eco-system
that has been built around link-state IGPs. i am particularly interested
how  TE use-cases requiring admission-control and pre-emption play with TTZ.

/hannes

---

From: Huaimo Chen <[email-masked]>
Date: Tue, 9 Jul 2013 19:33:37 +0000

Hi Hannes,

    Thanks for your comments!
    See my responses in line below.

Best Regards,
Huaimo
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Gredler
Sent: Tuesday, July 09, 2013 1:21 PM
To: Acee Lindem
Cc: OSPF List
Subject: Re: [OSPF] OSPF Topology Transparent Zone (TTZ) Next Steps

scaling a link-state protocols route-calculation path (SPF and RIB-Walk) to support 1000s of nodes is an already solved problem.
solving it again, (just different this time) is of limited use ...

[Huaimo] How about 10,000s or 100,000s of nodes? 

quite contrary - i fail to see how *hiding* information (i.e. nodes and links along with their TE attributes) does not break some of the TE eco-system that has been built around link-state IGPs. i am particularly interested how  TE use-cases requiring admission-control and pre-emption play with TTZ.

[Huaimo] Regarding to TE, we are working on it and have some solutions.

/hannes

---

From: Peter Psenak <[email-masked]>
Date: Tue, 09 Jul 2013 22:21:40 +0200

Huaimo,

OSPF has the concept of areas, which allows you to scale if needed. ABR 
part is also the most complex part of the OSPF protocol and TTZ is of 
the same if not higher complexity.

I do not believe current area architecture has reached its scaling 
limits which would require an introduction of the new protocol mechanism.

In short, you need to find some other applicability of the TTZ, scaling 
is simply not the relevant one.

my 2c,
Peter

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 11 Jul 2013 18:22:36 +0000

Hi Peter,

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

Best Regards,
Huaimo
-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Tuesday, July 09, 2013 4:22 PM
To: Huaimo Chen
Cc: OSPF List
Subject: Re: [OSPF] OSPF Topology Transparent Zone (TTZ) Next Steps

Huaimo,

OSPF has the concept of areas, which allows you to scale if needed. ABR part is also the most complex part of the OSPF protocol and TTZ is of the same if not higher complexity.

I do not believe current area architecture has reached its scaling limits which would require an introduction of the new protocol mechanism.

In short, you need to find some other applicability of the TTZ, scaling is simply not the relevant one.

[Huaimo] Using TTZ to avoid splitting one area into multiple areas may have some advantages in some cases such as: TTZ may make TE easier. For a network having one area with multiple TTZs, an operator configures a TE LSP crossing multiple TTZs just like s/he configures the LSP in one area. S/he just needs give a source, a destination, and maybe some constraints for the LSP. If one area in divided into multiple areas, configuring a TE LSP crossing multiple areas are complex. 

my 2c,
Peter

On 9.7.2013 21:33, Huaimo Chen wrote:
>>   Applicability: 
>> http://www.ietf.org/id/draft-chen-ospf-ttz-app-03.txt
>
>
>

---

From: Peter Psenak <[email-masked]>
Date: Thu, 11 Jul 2013 21:27:25 +0200

Hi Huaimo,

please see inline:

> [Huaimo] Using TTZ to avoid splitting one area into multiple areas may have some advantages in some cases such as: TTZ may make TE easier. For a network having one area with multiple TTZs, an opera…

even if it's easier to do TE with TTZ then with multiple areas, which 
I'm not convinced about, it still does not look like a sufficient reason 
to add TTZ extension to a protocol.

thanks,
Peter