Hi Chris,
Thank you very much for your comments.
My answers/explanations are inline below with prefix [HC].
Best Regards,
Huaimo
________________________________
From: Christian Hopps
Sent: Tuesday, July 7, 2020 9:21 PM
To: Huaimo Chen
Cc: Christian Hopps; Acee Lindem (acee); [email protected]; [email protected]
Subject: Re: [Lsr] Request WG adoption of TTZ
> On Jul 7, 2020, at 8:42 PM, Huaimo Chen <[email protected]> wrote:
>
> Hi Acee and Chris,
>
> Thank you very much for your comments.
>
> > I agree with Chris – when the IS-IS TTZ draft adopted the approach of
> > having the area/zone leader originate a single LSP abstracting the
> > zone/area last Oct, the main differentiation between the two approaches is
> > the zone/area terminology. The other substantive difference is the fact
> > that the Area Proxy draft includes a much more comprehensive specification
> > of the protocol mechanisms required for area/zone abstraction. I have no
> > doubt that the Area Proxy details could also be amended from area proxy to
> > TTZ, but that is exactly Chris’s point with which I agree – there
> > essentially isn’t a difference.
>
> Thanks,
> Acee
>
> There are really some differences between TTZ and Area Proxy, which are
> listed below for OSPF and IS-IS:
> Differences between OSPF TTZ and OSPF Area Proxy (note: assume that OSPF
> Area Proxy is similar to IS-IS Area Proxy even though OSPF Area Proxy is not
> defined in the Area Proxy draft) include:
> 1). It seems that OSPF Area Proxy can not be amended to OSPF TTZ. OSPF
> TTZ abstracts a zone to a single pseudo node. This abstraction is supported
> by the extensions to OSPF, and some of these extensions are not defined in
> OSPF Area Proxy. For example, the extensions for the edge nodes of the zone
> are not defined in OSPF Area Proxy.
> 2). OSPF Area Proxy abstracts an existing OSPF area to a single pseudo
> node. OSPF TTZ abstracts a zone to a single pseudo node. A zone is a piece
> or block of an OSPF area. An OSPF area is different from a zone in general.
> 3). The ways in which they are applied to an OSPF area for scalability
> are different. When an OSPF area becomes bigger and bigger, we may have
> scalability issues. Using OSPF TTZ, we can abstract one or a few zones in the
> OSPF area to one or few pseudo nodes smoothly without any interface down.
> Using OSPF Area Proxy, we need split the existing OSPF area into multiple
> OSPF areas, and then abstract one or a few OSPF areas to one or few pseudo
> nodes. Some people may like the one step operation in OSPF TTZ. Others may
> like the two step operations in OSPF Area Proxy.
> 4). The user experiences are different. For splitting an existing OSPF
> area into multiple OSPF areas, users may need put more efforts since it
> causes service interruptions in general. While splitting an OSPF area into
> multiple OSPF areas, the area numbers configured on some interfaces will be
> changed and each of these interfaces will be down with its old area number
> and then up with its new area number.. These interface downs and ups will
> cause service interruptions in general.. For defining zones in an OSPF area,
> users may need less efforts since abstracting a zone to a single pseudo node
> is smooth without any interface down.
> 5). OSPF TTZ provides smooth transferring between a zone and its single
> pseudo node. That is that a zone can be smoothly transferred to a single
> pseudo node, and the pseudo node can be smoothly rolled back to the zone..
I think the fact that the above is mixing terms (e.g., OSPF Area Proxy, which
doesn't exist, and OSPF doesn't have pseudo-nodes) is really highlighting the
fact that, as Acee pointed out, perhaps its not a good idea to be trying to
update/modify OSPF TTZ (RFC8099), and at the same time introduce something new
to IS-IS. It's very confusing right now to have these things all mixed together
like this.
[HC]: OSPF Area Proxy does not exist and it seems that Tony is not interested
in it. In this case, I think that abstracting a zone to a single node should be
moved forward. It should extends RFC 8099, not update/modify RFC 8099.
For IS-IS TTZ, it just needs two new TLVs now, which can be reduced to one. It
seems there is not much confusing. I think that it should be moved forward too.
For the terms such as pseudo nodes, they can be easily changed if they are not
good.
Thanks,
Chris.
[As WG member]
>
> Differences between IS-IS TTZ and IS-IS Area Proxy are similar to
> the above 1). 2). 3). and 5) between OSPF TTZ and OSPF Area Proxy.
>
> Best Regards,
> Huaimo
> From: Acee Lindem (acee) <[email protected]>
> Sent: Tuesday, July 7, 2020 3:41 PM
> To: Huaimo Chen <[email protected]>; Christian Hopps
> <[email protected]>
> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>
> Subject: Re: [Lsr] Request WG adoption of TTZ
>
> Speaking as WG member:
>
> I agree with Chris – when the IS-IS TTZ draft adopted the approach of having
> the area/zone leader originate a single LSP abstracting the zone/area last
> Oct, the main differentiation between the two approaches is the zone/area
> terminology. The other substantive difference is the fact that the Area Proxy
> draft includes a much more comprehensive specification of the protocol
> mechanisms required for area/zone abstraction. I have no doubt that the Area
> Proxy details could also be amended from area proxy to TTZ, but that is
> exactly Chris’s point with which I agree – there essentially isn’t a
> difference.
>
> Thanks,
> Acee
> From: Lsr <[email protected]> on behalf of Huaimo Chen
> <[email protected]>
> Date: Tuesday, July 7, 2020 at 12:01 PM
> To: Christian Hopps <[email protected]>
> Cc: "[email protected]" <[email protected]>, "[email protected]"
> <[email protected]>
> Subject: Re: [Lsr] Request WG adoption of TTZ
>
> Hi Chris,
>
> Thank you very much for your questions.
> My answers/explanations are inline below with prefix [HC].
>
> Best Regards,
> Huaimo
> From: Christian Hopps
> Sent: Tuesday, July 7, 2020 8:08 AM
> To: Huaimo Chen
> Cc: Christian Hopps; [email protected]; [email protected]
> Subject: Re: [Lsr] Request WG adoption of TTZ
>
> Hi Huaimo,
>
> Can you speak to the differences of this with Area Proxy? They are similar
> solutions, right?
>
> [HC]: There are some differences even though they looks similar.
> At first, the target to be abstracted in Area Proxy is different from that in
> TTZ.
> Area Proxy abstracts an existing area to a single pseudo node.
> TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of
> an area.
> An area is different from a zone in general.
>
> Secondly, the ways in which they are applied to an area for scalability are
> different.
> When an area becomes bigger and bigger, we may have scalability issues..
> Using TTZ, we can abstract one or a few zones in the area to one or few
> pseudo nodes smoothly without any interface down. Using Area Proxy, we need
> split the existing area into multiple areas, and then abstract one or a few
> areas to one or few pseudo nodes.
> These differences will produce different user experiences.
> For splitting an existing area into multiple areas, users may need put more
> efforts since it causes service interruptions in general. While splitting an
> area such as an OSPF area into multiple areas, the area numbers configured on
> some interfaces will be changed and each of these interfaces will be down
> with its old area number and then up with its new area number. These
> interface downs and ups will cause service interruptions in general.
> For defining zones in an area, users may need less efforts since abstracting
> a zone to a single pseudo node is smooth without any interface down.
>
> Moreover, TTZ provides smooth transferring between a zone and its single
> pseudo node. That is that a zone can be smoothly transferred to a single
> pseudo node, and the pseudo node can be smoothly rolled back to the zone.
>
> BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to
> a single pseudo node.
> In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo
> node, and a zone in an IS-IS area to a single pseudo node.
>
>
> There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so
> i found it confusing to have this document also talking about TTZ for OSPF;
> is it redefining it, updating it, just referring to it?
>
> [HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for
> abstracting a zone to the zone edges full mess. This document proposes a new
> solution for abstracting a zone to a single pseudo node. The new solution
> re-uses some of RFC 8099, to which are referred. The new extensions to OSPF
> for the new solution are defined in the document.
>
> Thanks,
> Chris.
> [chair hat]
>
>
> > On Jun 18, 2020, at 11:38 PM, Huaimo Chen <[email protected]> wrote:
> >
> > Hi Chris and Acee, and everyone,
> >
> >
> >
> > I would like to request working group adoption of "Topology-Transparent
> > Zone"
> >
> > (TTZ for short) https://datatracker.ietf.org/doc/draft-chen-isis-ttz/ .
> >
> >
> >
> > This draft comprises the following solutions for helping to improve
> > scalability:
> >
> > 1) abstracting a zone to a single pseudo node in IS-IS,
> >
> > 2) abstracting a zone to a single pseudo node in OSPF,
> >
> > 3) abstracting a zone to zone edges' full mess in IS-IS, and
> >
> > 4) transferring smoothly between a zone and a single pseudo node.
> >
> > A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone or
> >
> > non-backbone area).
> >
> >
> >
> > When a network area becomes (too) big, we can reduce its size in the
> > sense
> >
> > of its LSDB size through abstracting a zone to a single pseudo node or
> >
> > abstracting a few zones to a few pseudo nodes.
> >
> >
> >
> > While a zone is being abstracted (or transferred) to a single pseudo
> > node,
> >
> > the network is stable. There is no or minimum service interruption.
> >
> >
> >
> > After abstracting a few zones to a few pseudo nodes, if we want to
> > reconstruct
> >
> > them, we can transfer (or roll) any of the pseudo nodes back to its zone
> > smoothly
> >
> > with no or minimum service interruption.
> >
> >
> >
> > We had a prototype implementation of abstracting a zone to zone edges'
> > full
> >
> > mess in OSPF. The procedures and related protocol extensions for
> > transferring
> >
> > smoothly from a zone to zone edges' full mess are implemented and tested.
> >
> > A zone (block of an OSPF area) is smoothly transferred to its edges’ full
> > mess
> >
> > without any routing disruptions. The routes on every router are stable while
> >
> > the zone is being transferred to its edges' mess. It is very easy to operate
> >
> > the transferring.
> >
> >
> >
> > There are two other drafts for improving scalability: "Area Proxy for
> > IS-IS"
> >
> > (Area Proxy for short) and "IS-IS Flood Reflection" (Flood Reflection for
> > short).
> >
> >
> >
> > "Area Proxy" https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03
> >
> > abstracts an existing IS-IS L1 area to a single pseudo node.
> >
> >
> >
> > "Flood Reflection"
> > https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01
> >
> > abstracts an existing IS-IS L1 area to its edges' connections via one or
> > more
> >
> > flood reflectors.
> >
> >
> >
> > We believe that TTZ has some special advantages even though
> >
> > Area Proxy and Flood Reflection are very worthy. We would like
> >
> > to ask for working group adoption of TTZ.
> >
> >
> > Best Regards,
> >
> > Huaimo
> >
> > _______________________________________________
> > Lsr mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/lsr
>
> _______________________________________________
> Lsr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
