Linda,
On 7/14/20, 1:57 PM, "Linda Dunbar" <linda.dun...@futurewei.com> wrote:
Acee,
Many networks have BGP or/and ISIS.
Encoding of BGP messages are discussed in IDR WG, and the encoding of ISIS
is discussed LSR WG.
The TTZ zone draft is about ISIS encoding of TTZ, therefore, the discussion
should be in the LSR Wg, instead of RTGwg (in my opinion).
Maybe, the discussion on why TTZ should replace BGP can be in RTGwg. But
this TTZ zone draft is not about replacing BGP.
But you just said "TTZ is another option?" And if IS-IS isn't running over the
SDWAN overlay, how is IS-IS TTZ even applicable to solving any problem in SDWAN?
Thanks,
Acee
Linda
-----Original Message-----
From: Acee Lindem (acee) <a...@cisco.com>
Sent: Tuesday, July 14, 2020 12:32 PM
To: Linda Dunbar <linda.dun...@futurewei.com>; Christian Hopps
<cho...@chopps.org>
Cc: LEI LIU <liu...@ieee.org>; Huaimo Chen <huaimo.c...@futurewei.com>;
lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ
Linda,
On 7/14/20, 1:26 PM, "Linda Dunbar" <linda.dun...@futurewei.com> wrote:
Acee,
We have deployment of using BGP to group a set of SDWAN nodes as one
entity and exchange link/paths/ports information among sites/nodes.
TTZ could be another option.
I don't see how it would work to replace BGP and RR with IS-IS TTZ for
SDWAN Fabric setup. However, that is probably a topic that would be better
addressed in the RTG WG.
Thanks,
Acee
Linda
-----Original Message-----
From: Acee Lindem (acee) <a...@cisco.com>
Sent: Tuesday, July 14, 2020 11:59 AM
To: Linda Dunbar <linda.dun...@futurewei.com>; Christian Hopps
<cho...@chopps.org>
Cc: LEI LIU <liu...@ieee.org>; Huaimo Chen <huaimo.c...@futurewei.com>;
lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ
Linda,
So the IS-IS runs over the overlay in your SDWAN solution? Have you
deployed this? __
Acee
On 7/14/20, 12:52 PM, "Linda Dunbar" <linda.dun...@futurewei.com> wrote:
Christian,
The SDWAN use case is about grouping a set of nodes in
geographically different locations to be one TTZ zone being treated as one
Virtual Node.
Linda
-----Original Message-----
From: Christian Hopps <cho...@chopps.org>
Sent: Saturday, July 11, 2020 6:42 AM
To: Linda Dunbar <linda.dun...@futurewei.com>
Cc: Christian Hopps <cho...@chopps.org>; LEI LIU <liu...@ieee.org>;
Huaimo Chen <huaimo.c...@futurewei.com>; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ
> On Jul 10, 2020, at 4:39 PM, Linda Dunbar
<linda.dun...@futurewei.com> wrote:
>
> I also support the adoption of TTZ draft.
>
> The Virtual Zone concept would be very useful for the Overlay
networks. The proposed TTZ can group a set of nodes not geographically together
into one virtual area to scale virtual overlay networks with lots of nodes.
Those kind overlay networks are getting more momentum in SDWAN and CDN
environment.
I'm not sure I follow this use-case. The intent of TTZ is to treat
a bunch of nodes as a single node (or subset of nodes in early work) to reduce
the link-state DB size and flooding requirements, AFAICT.
Thanks,
Chris.
[As WG member]
>
> Linda Dunbar
>
> From: Lsr <lsr-boun...@ietf.org> On Behalf Of LEI LIU
> Sent: Friday, July 10, 2020 12:42 PM
> To: Huaimo Chen <huaimo.c...@futurewei.com>
> Cc: lsr@ietf.org; lsr-cha...@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
>
> I support the adoption of the TTZ draft.
>
> The operation on TTZ is simple. Smooth transferring between a
zone and a single node will improve customer experience. The work on TTZ should
be moved forward.
>
> Thanks,
> Best regards,
>
> Lei
>
> On Thu, Jun 18, 2020 at 8:38 PM Huaimo Chen
<huaimo.c...@futurewei.com> wrote:
> Hi Chris and Acee, and everyone,
>
>
>
> I would like to request working group adoption of
"Topology-Transparent Zone"
>
> (TTZ for short)
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cd8af0da5bafd40e70fce08d8281bd3e7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303447263980613&sdata=L8xHMIno4kitHe9mnfLNJ0yeRTbRrKX3gVK6AnbAet4%3D&reserved=0
.
>
>
>
> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-lsr-isis-area-proxy-03&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cd8af0da5bafd40e70fce08d8281bd3e7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303447263980613&sdata=y84q%2B9%2FYddSZo%2FYEDgPNWgByUl2IzxVdrKAGqTAPxHE%3D&reserved=0
>
> abstracts an existing IS-IS L1 area to a single pseudo node.
>
>
>
> "Flood Reflection"
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-przygienda-lsr-flood-reflection-01&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cd8af0da5bafd40e70fce08d8281bd3e7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303447263980613&sdata=3yJFlhcApc9Bi1sOlJpHNy96Ux9TIVVXLFT0YXWXrWo%3D&reserved=0
>
> 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
> Lsr@ietf.org
>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cd8af0da5bafd40e70fce08d8281bd3e7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303447263980613&sdata=LMpTmkWQy6eTxYdEdYMcuhz%2BI6jq%2B3Z3V1SVV86VDjc%3D&reserved=0
>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cd8af0da5bafd40e70fce08d8281bd3e7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303447263980613&sdata=LMpTmkWQy6eTxYdEdYMcuhz%2BI6jq%2B3Z3V1SVV86VDjc%3D&reserved=0
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
