Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt
Support as a co-author. Thanks, Best regards, Lei On Tue, Aug 18, 2020 at 7:17 AM Acee Lindem (acee) wrote: > > > Based on the discussions in the last meeting and on the mailing list > regarding draft-chen-isis-ttz-11, the chairs feel that there are enough > differences with draft-ietf-lsr-isis-area-proxy-03 and in the community to > consider advancing it independently on the experimental track. > > > > These differences include abstraction at arbitrary boundaries and IS-IS > extensions for smooth transition to/from zone abstraction. > > > > We are now starting an LSR WG adoption call for > draft-chen-isis-ttz-11.txt. Please indicate your support or objection to > adoption prior to Tuesday, September 2nd, 2020. > > > > Thanks, > > Acee and Chris > > > ___ > 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] LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz.txt
I’m not aware of any IPR associated with this draft. Thanks, Best regards, Lei On Tue, Aug 18, 2020 at 7:24 AM Acee Lindem (acee) wrote: > Authors, > > > > The IETF IPRs declarations submitted for draft-chen-isis-ttz are specified > here: > > > > https://datatracker.ietf.org/ipr/4029/ > > > > > > Are you aware of any other IPR that applies to draft-chen-isis-ttz? > > > > If so, has this IPR been disclosed in compliance with IETF IPR rules > > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > > > If you are listed as a document author or contributor please respond > > to this email regardless of whether or not you are aware of any > > relevant IPR. *The response needs to be sent to the LSR WG mailing > > list.* The document will not advance to the next stage until a > > response has been received from each author and contributor. > > > > If you are on the LSR WG email list but are not listed as an author or > > contributor, then please explicitly respond only if you are aware of > > any IPR that has not yet been disclosed in conformance with IETF rules. > > > > Thanks, > > Acee > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
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 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] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
Support it as a co-author. Thanks, Best regards, Lei On Fri, May 15, 2020 at 12:40 PM Acee Lindem (acee) wrote: > This begins a 3 week (due to holidays) WG adoption call for the “Flooding > Topology Computation Algorithm” draft. Please issue your support or > objection to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL > for your convenience. > > > > https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/ > > > > Thanks, > Acee > ___ > 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] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 IPR Poll
Hi, Acee, I am not aware of any IPR that applies to draft-cc-lsr-flooding-reduction-08. Best Regards. Lei On Fri, May 15, 2020 at 12:47 PM Acee Lindem (acee) wrote: > Authors, > > > > Are you aware of any IPR that applies > to draft-cc-lsr-flooding-reduction-08.txt. > > > > If so, has this IPR been disclosed in compliance with IETF IPR rules > > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > > > If you are listed as a document author or contributor please respond > > to this email regardless of whether or not you are aware of any > > relevant IPR. *The response needs to be sent to the LSR WG mailing > > list.* The document will not advance to the next stage until a > > response has been received from each author and contributor. > > > > If you are on the LSR WG email list but are not listed as an author or > > contributor, then please explicitly respond only if you are aware of > > any IPR that has not yet been disclosed in conformance with IETF rules. > > > > Thanks, > > Acee > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
Hi All, In favor of adopting both drafts in parallel, and then one draft focuses on the centralized solution and the other on the distributed solution. Best regards, Lei On Mon, Feb 11, 2019 at 2:47 AM Christian Hopps wrote: > > Hi Folks, > > We are starting a 2 week adoption call on draft-li-lsr-dynamic-flooding-02. > > The aim of this document is to describe the problem space and standardize > a way to signal dynamic flooding information. It does not standardize any > specific algorithm for flooding topology creation. > > Authors please respond indicating if you are aware of any IPR related to > this work. > > We also have another draft (draft-cc-lsr-flooding-reduction-01) that > started as a distributed flooding topology algorithm and morphed into that > plus competing ideas on signaling of flooding topology information. The > intent after adoption of draft-li-lsr-dynamic-flooding-02 is two-fold. One, > the WG can discuss adding any signaling ideas from this work to the adopted > signaling draft (with proper attribution given as appropriate), and two, > for the authors of draft-cc-lsr-flooding-reduction-01 to publish a new > document without the signaling portion and instead focus on their flooding > topology algorithm. This new focused document can be considered in parallel > along with the other algorithm work that has been proposed. > > Flooding topology creation is seen as a hard problem for which we don't > expect a one-size-fits-all solution. Taking the steps outlined above will > help us move forward on the solutions. > > Thanks, > Chris & Acee. > LSR WG Chairs. > ___ > 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
