Re: [Lsr] Request WG adoption of TTZ

[Uma Chunduri]

 I would support the IS-IS TTZ solution for WG adoption.


Of course, obviously not with OSPF encodings or concepts only relevant to
OSPF (thx for the updated version).

Thanks for the good work which was started way back on TTZs with OSPF
protocol first (RFC 8099).


I will send my specific comments/suggestions a bit later.

--

Uma C.



On Thu, Jun 18, 2020 at 8:38 PM Huaimo Chen 
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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request WG adoption of TTZ

[Haoyu Song]

IS-IS TTZ is useful and I support the adoption of the TTZ draft too.
Thanks!

Haoyu
From: Linda Dunbar 
Sent: Friday, July 10, 2020 1:40 PM
To: LEI LIU ; Huaimo Chen 
Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

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.

Linda Dunbar

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of LEI 
LIU
Sent: Friday, July 10, 2020 12:42 PM
To: Huaimo Chen mailto: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 
mailto: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://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
Lsr@ietf.org

Re: [Lsr] Request WG adoption of TTZ

[Linda Dunbar]

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.

Linda Dunbar

From: Lsr  On Behalf Of LEI LIU
Sent: Friday, July 10, 2020 12:42 PM
To: Huaimo Chen 
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 
mailto: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://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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request WG adoption of TTZ

[LEI LIU]

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 
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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request WG adoption of TTZ

[Donald Eastlake]

I support adoption of the IS-IS TTZ draft.

It seems more flexible and capable although some
editorial/nomenclature improvements in the draft would be good. I will
send some more detailed suggestions to the authors.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Thu, Jun 18, 2020 at 11:38 PM Huaimo Chen  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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] I-D Action: draft-ietf-lsr-flex-algo-08.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : IGP Flexible Algorithm
Authors : Peter Psenak
  Shraddha Hegde
  Clarence Filsfils
  Ketan Talaulikar
  Arkadiy Gulko
Filename: draft-ietf-lsr-flex-algo-08.txt
Pages   : 36
Date: 2020-07-10

Abstract:
   IGP protocols traditionally compute best paths over the network based
   on the IGP metric assigned to the links.  Many network deployments
   use RSVP-TE based or Segment Routing based Traffic Engineering to
   enforce traffic over a path that is computed using different metrics
   or constraints than the shortest IGP path.  This document proposes a
   solution that allows IGPs themselves to compute constraint based
   paths over the network.  This document also specifies a way of using
   Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets
   along the constraint-based paths.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-08
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-flex-algo-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr