[Lsr] Fwd: New Version Notification for draft-li-area-abstraction-00.txt

2018-06-29 Thread tony . li
New Version Notification for draft-li-area-abstraction-00.txt > Date: June 29, 2018 at 3:28:05 PM PDT > To: "Tony Li" > > > A new version of I-D, draft-li-area-abstraction-00.txt > has been successfully submitted by Tony Li and posted to the > IETF repository. &

[Lsr] Fwd: New Version Notification for draft-li-hierarchical-isis-00.txt

2018-06-29 Thread tony . li
FYI: This extends IS-IS from 2 levels to 8. Comments are most welcome! Regards, Tony > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-li-hierarchical-isis-00.txt > Date: June 29, 2018 at 4:12:24 PM PDT

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-24 Thread tony . li
So, going Old Skool here: Since everyone agrees that this is a reasonable direction, how about we have a real discussion on the list? Requirement number 1 is straightforward: a significant reduction in flooding overhead. The basis for this requirement is the understanding that in a dense

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-24 Thread tony . li
> a) we are talking any kind of topology for the solution, i.e. generic graph? Well, the problem with a topology restriction is that mistakes happen. If we have a solution for a pure bipartite graph (i.e., a leaf-spine topology) and someone mistakenly inserts a leaf to leaf link, what

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-24 Thread tony . li
> I think distributed is more practical too. I would appreciate more detailed insights as to why you (and others) feel this way. It is not at all obvious to me. > For computing routes, we have been using distributed SPF on every node for > many years. True, but that algorithm is (and

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-24 Thread tony . li
Tony, > as to miscabling: yepp, the protocol has either to prevent adjacencies coming > up or one has to deal with generic topologies. If you don't want to design > miscabling prevention/topology ZTP into protocol (like ROLL or RIFT did) you > have to deal with generic graph as you say. I

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-28 Thread tony . li
> Can we focus on finding one common algorithms that can deducing the optimized > flooding topology based on the initial synchronized LSDB for further LSA > flooding reduction? We welcome proposals for algorithms that fulfill the requirements that have been discussed. So far …. crickets.

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-27 Thread tony . li
> so it's party like it's 1999, seems the peer group leader election gets > rediscovered ;-) Interesting old new problems, interesting old new attack > vectors like https://ieeexplore.ieee.org/document/822780/ > No argument there. There are no

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-22 Thread Tony Li
> At IETF 102, there was no dearth of flooding reduction proposals. In fact, > we have so many proposals that there wasn’t agree as how to move forward and > we agreed to discuss on the list. This Email is to initiate that discussion > (which I intend to participate in but as a WG member).

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-27 Thread tony . li
Hi Huaimo, > After flooding reduction is deployed in an operational (ISP) network, will we > be allowed to do experiments on their network? Some may well permit it. Certainly in lab scenarios they may be very willing. It all depends on their motivation to achieve improvements. It should

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-27 Thread tony . li
> Today’s DR or DIS election is local to a special interface/network such as a > broadcast interface. Leader election in a network is global. Every node in > the network depends on it (its flooding topology). These two seems different. Hmm…. Ethernet is not ‘special’. Pretty much all that

Re: [Lsr] Fwd: New Version Notification for draft-li-dynamic-flooding-04.txt

2018-04-06 Thread tony . li
Hi Peter, Thank you for your comments. > while I appreciate the flexibility associated with the centralized > computation of the flooding topology, it has some drawbacks as well: > > 1. "flooding topology" must be flooded. This makes the flooding dependent on > the flooded data itself.

Re: [Lsr] FW: New Version Notification for draft-ginsberg-isis-rfc7810bis-00.txt

2018-04-04 Thread Tony Li
I don’t see the big deal in having the WG name in the draft title, even for category 1 documents. It’s only the name of the draft and the fact that it is protocol specific doesn’t really need to be called out at that level. People who read the document will certainly figure it out. Tony On

Re: [Lsr] Fwd: New Version Notification for draft-li-dynamic-flooding-04.txt

2018-04-17 Thread tony . li
Acee, > I think a distributed flooding algorithm is more robust and will converge > faster when there more than one concurrent failure in the flooding topology. No doubt. However, we do not normally attempt to protect against multiple concurrent failures. Regardless of how the flooding

[Lsr] Fwd: New Version Notification for draft-li-dynamic-flooding-04.txt

2018-03-27 Thread tony . li
gin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-li-dynamic-flooding-04.txt > Date: March 27, 2018 at 9:01:30 AM PDT > To: "Tony Li" <tony...@tony.li> > > > A new version of I-D, draft-li-dynamic-floodi

[Lsr] Fwd: New Version Notification for draft-li-dynamic-flooding-05.txt

2018-06-28 Thread tony . li
t; > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-li-dynamic-flooding-05.txt > Date: June 28, 2018 at 8:42:07 AM PDT > To: "Peter Psenak" , "Tony Li" > > > A new version of I-D, draft-li-dynamic-flooding-05.txt > has

[Lsr] Fwd: New Version Notification for draft-li-lsr-dynamic-flooding-00.txt

2018-10-21 Thread tony . li
: "Tony Przygienda" , "Peter Psenak" , > "Dave Cooper" , "Tony Li" , "Les Ginsberg" > > > > A new version of I-D, draft-li-lsr-dynamic-flooding-00.txt > has been successfully submitted by Peter Psenak and posted to the > IET

[Lsr] Side meeting: Flooding reduction

2018-11-06 Thread tony . li
Hi all, I would like to invite all interested parties to a side meeting to discuss (and resolve) our direction on the LSR flooding proposals. Time: 9am Friday, Nov. 9 Location: Boromphimarn 3 Please RSVP unicast to me. If I don’t see a critical mass of responses within 24 hours, I will mail

Re: [Lsr] Side meeting: Flooding reduction

2018-11-08 Thread tony . li
Folks, I’m sorry to say that we weren’t able to achieve critical mass. Meeting canceled. Tony > On Nov 7, 2018, at 10:00 AM, tony...@tony.li wrote: > > > Hi all, > > I would like to invite all interested parties to a side meeting to discuss > (and resolve) our direction on the LSR

Re: [Lsr] LSR: Using DSCP for path/topology selection Q

2018-11-15 Thread Tony Li
> On Nov 15, 2018, at 8:47 PM, Jeff Tantsura wrote: > > The question is really - what is here to standardize? There’s a fine architectural BCP here: this is how we are solving problem XYZ. Please don’t break this. Tony ___ Lsr mailing list

Re: [Lsr] IS-IS over TCP

2018-11-06 Thread tony . li
Les, > On Nov 7, 2018, at 11:09 AM, Les Ginsberg (ginsberg) > wrote: > > 2)Your statements regarding existing flooding limitations of IS-IS are rather > dated. Many years ago implementations varied from the base specification by > allowing much faster flooding and contiguous flooding bursts

[Lsr] IS-IS over TCP

2018-11-05 Thread tony . li
Per the WG meeting, discussing on the list: This is good work and I support it. I would remind folks that TCP is NOT the only transport protocol available and that perhaps we should be considering QUIC while we’re at it. In particular, flooding is a (relatively) low bandwidth operation in

Re: [Lsr] Teasing us with secrets

2018-11-12 Thread tony . li
Les, > Discussion of bypassing the ISO 10589 flooding pacing timer was done in > public many years ago when sub-second convergence was introduced. > Here is one public paper: > > https://inl.info.ucl.ac.be/publications/achieving-sub-second-igp-convergence-.html > > There are also multiple

Re: [Lsr] Teasing us with secrets

2018-11-12 Thread tony . li
best thing to do is > update that RFC. > > I would however like us to agree that the subject of this thread is > inappropriate. :-) > > Les > > >> -Original Message- >> From: Tony Li On Behalf Of tony...@tony.li >> Sent: Monday, November

Re: [Lsr] WG Adoption Call for "IS-IS Routing for Spine-Leaf Topology" - draft-shen-isis-spine-leaf-ext-07

2018-12-01 Thread tony . li
I support adopting this draft. Tony > On Dec 1, 2018, at 4:54 PM, Acee Lindem (acee) wrote: > > This begins a two-week WG adoption call for the subject draft. As anyone who > has been following the topic knows, there are a lot of proposal in this > space. However, as WG co-chair, I believe

[Lsr] Fwd: New Version Notification for draft-li-lsr-isis-hierarchical-isis-00.txt

2018-12-07 Thread tony . li
at 10:31:08 AM PST > To: "Tony Li" > > > A new version of I-D, draft-li-lsr-isis-hierarchical-isis-00.txt > has been successfully submitted by Tony Li and posted to the > IETF repository. > > Name: draft-li-lsr-isis-hierarchical-isis > Revision: 00 >

[Lsr] Fwd: New Version Notification for draft-li-lsr-isis-area-abstraction-00.txt

2018-12-07 Thread tony . li
are encouraged. Happy holidays, Tony > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for > draft-li-lsr-isis-area-abstraction-00.txt > Date: December 7, 2018 at 10:15:01 AM PST > To: "Tony Li" > > >

Re: [Lsr] On flooding, diameter, and degree

2018-11-19 Thread tony . li
Dave, Thanks very much for commenting. I’m a bit confused about your column “Receipt Degree” and perhaps how flooding works in your proposal. Let’s use the example from your section 4.2, where ‘a’ and ‘z’ are the roots and there are only two tiers. Suppose that ‘a’ has an update. It

[Lsr] On flooding, diameter, and degree

2018-11-19 Thread tony . li
Hi all, I’d like to expound a bit more on a point that I made at the mike in Bangkok. The figures of merit for a flooding algorithm are the resulting diameter of the flooding topology and the maximum degree of the nodes in the topology. The diameter is important because it says how many hops

Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

2019-04-02 Thread tony . li
I am in complete agreement with both Les’s extensive analysis and opinion. ;-) Tony > On Apr 2, 2019, at 8:37 AM, Les Ginsberg (ginsberg) > wrote: > > In reply to my own post, here is my opinion regarding including LANs in the > Flooding Topology: > > While I think it would be "nice" and

Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

2019-04-02 Thread tony . li
Hello Robert, > For the purpose of this discussion can someone quote the definition of LAN ? Well, sure, if you insist. I’m surprised as you’ve been around for (quite) awhile and I would have thought that you picked up on this stuff. :-) :-) :-) ISO 10589v2 defines a LAN as a “Local Area

Re: [Lsr] Open issues with Dynamic Flooding

2019-04-02 Thread tony . li
Hi Huaimo, > Can you give some details about: what is the rate limiting link addition and > how does it (the rate limiting link addition) fix or help fix the flooding > topology (FT) split when multiple failures occur on FT? The details of the wording will have to wait until someone (probably

Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

2019-04-02 Thread tony . li
Hi Tony, > As to signalling, I think we have not much choice and need to signal the > PNODE as either being in or out topology which implies LAN is in or out it > ... I would also consider optimizations to "sub-flood" the LAN (i.e. > disaggregate it to p2p floodings or nodes dropping

Re: [Lsr] LANs in IGPs

2019-04-03 Thread tony . li
Hi Robert, > But I really think this isn’t relevant. The use of LANs in the flooding > topology is only meaningful if we have a multi-access circuit which is used > for transit traffic. And at least some of us are leaning to allowing for that > possibility – which is not at all the same thing

Re: [Lsr] Flooding Path Direction

2019-04-04 Thread tony . li
Hi Dave, > The algorithm in draft-allan actually has the notion of upstream, downstream > and both upstream and downstream FT adjacencies. However as a generalized > form is still a WIP and has yet to demonstrate merit against any of the > other approaches on the table, I'd not be looking to

Re: [Lsr] When to augment LSR base YANG modules...

2019-03-29 Thread tony . li
Chris, One concern is simply one of scale: doing this will increase the size of the document. At what point do things become sufficiently awkward that we want to have a separate, concurrent document. In other words, if the requirement is for concurrent delivery, is co-location really a

Re: [Lsr] FW: New Version Notification for draft-white-distoptflood-00.txt

2019-04-01 Thread tony . li
> >> 3)The adjacency formation logic discussed in Section 2 isn’t directly >> relevant >> to calculating a flooding topology. There are existing implementations which >> use the techniques you define as a means of reducing redundant flooding >> associated with adjacency bringup when there are

Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

2019-04-01 Thread tony . li
Hi Huaimo, Thank you for your note. I have many questions, please see inline. > When multiple (i.e., two or more) failures on the current flooding topology > (FT for short) happen at almost the same time, the FT may be split even > though the real network topology is connected. A solution

Re: [Lsr] Open issues with Dynamic Flooding

2019-04-01 Thread tony . li
Hi all, I hope that everyone had a safe and uneventful trip home from Prague and that no one else had the seat right in front of the screaming baby. ;-) I would like to re-open the discussion on the mailing list. Based on the off-line discussions that I had with folks, I believe that we’re

[Lsr] Fwd: Open issues with Dynamic Flooding

2019-04-08 Thread tony . li
Hi all, It’s been another week and we’ve had a few more very interesting conversations, but we seem to have not moved very far. Have we converged? Tony > Hi all, > > I hope that everyone had a safe and uneventful trip home from Prague and that > no one else had the seat right in front of

[Lsr] Open issues with Dynamic Flooding

2019-03-04 Thread tony . li
Hello, There are still two issues that need to be discussed and I was hoping that we could make progress on the mailing list before Prague. 1) Temporary additions to the flooding topology There are several cases where we would like to make temporary additions to the flooding topology:

Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

2019-02-20 Thread Tony Li
Hi Huaimo, > The way in which the flooding topology converges in the centralized > mode/solution is different from > that in the distributed mode/solution. In the former, after receiving the > link states for the failures, > the leader computes a new flooding topology and floods it to every

Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

2019-02-26 Thread Tony Li
Hi Huaimo, > > > 1) There is no concrete procedure/method for fault tolerance > > > to multiple failures. When multiple failures happen and split the > > > flooding topology, the convergence time will be increased > > > significantly without fault tolerance. The longer the convergence

[Lsr] Multiple failures in Dynamic Flooding

2019-03-06 Thread tony . li
Hi Huaimo, > > I’m sorry that you don’t find it useful. Determining the split is trivial: > > when you receive an IIH, > > it has a system ID of the another system in it. If that other system is not > > currently part of the > > flooding topology, then it is quite clear that it is

Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

2019-02-24 Thread Tony Li
> On Feb 24, 2019, at 3:14 PM, Christian Hopps wrote: > >> In distributed mode the area leader is >> the one that advertises the algorithm that is used by all nodes that >> participates in dynamic flooding. > > I'd like to suggest that as this point is discussed we are careful to not try >

Re: [Lsr] Open issues with Dynamic Flooding

2019-03-05 Thread tony . li
Peter, >>(a) Temporarily add all of the links that would appear to remedy the >> partition. This has the advantage that it is very likely to heal the >> partition and will do so in the minimal amount of convergence time. > > I prefer (a) because of the faster convergence. > Adding all

Re: [Lsr] Open issues with Dynamic Flooding

2019-03-05 Thread tony . li
>> LS topologies can have a very large number of adjacencies as well, >> typically with multiple spines, so for a new spine, all of the of the >> links may be unnecessary. > > ok, we talked bout the balance before - adding one link at a time to the FT > may result in slow recovery, while adding

Re: [Lsr] Open issues with Dynamic Flooding

2019-03-05 Thread tony . li
Hi Dave, > My understanding of this whole endeavor is that: > > - excessive flooding slows convergence > - so we are seeking to define a reduced flooding topology > - a failure that does not impact an FT adjacency is propagated throughout the > topology and the effects of excessive flooding

Re: [Lsr] Clarification on co-existance of dynamic flooding aware and not aware nodes

2019-03-07 Thread tony . li
> On Mar 7, 2019, at 3:16 AM, Robert Raszuk wrote: > > And precisely to that point I have tried to indicate that if this is by > design there is no point of including those 100s of TORs in constructing and > distributing flooding graph. And to the point of the algorithm, including those

Re: [Lsr] Open issues with Dynamic Flooding

2019-03-07 Thread tony . li
> On Mar 5, 2019, at 1:31 PM, tony...@tony.li wrote: > > Let me propose that we add something to sections 6.7.5, 6.7.9, and 6.7.11 > like: > > Addition of temporary flooding should be done with caution, as the addition > of excessive connectivity to the flooding topology may trigger unwanted

Re: [Lsr] Clarification on co-existance of dynamic flooding aware and not aware nodes

2019-03-07 Thread tony . li
> Well unless they know by design to always flood when peer is not dynamic > flooding capable. That would be an extremely detailed piece of corner case coding. ;-) > > Yes today this seems to be consider transient and rather an exception > (example bootstraping or incremental deployment).

Re: [Lsr] Open issues with Dynamic Flooding

2019-03-07 Thread tony . li
Les, > Let me propose that we add something to sections 6.7.5, 6.7.9, and 6.7.11 > like: > > Addition of temporary flooding should be done with caution, as the addition > of excessive connectivity to the flooding topology may trigger unwanted > behavior. Routers SHOULD add temporary flooding

Re: [Lsr] Multiple failures in Dynamic Flooding

2019-03-11 Thread tony . li
Hi Huaimo, > In summary for multiple failures, two issues below in > draft-li-lsr-dynamyic-flooding are discussed: > 1) how to determine the current flooding topology is split; and > 2) how to repair/connect the flooding topology split. > For the first issue, the discussions are

Re: [Lsr] Open issues with Dynamic Flooding

2019-03-07 Thread tony . li
> What does 'rate limit' mean in this context? It means that implementations get to decide how quickly they make temporary additions to the flooding topology. T ___ 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.

2019-02-11 Thread tony . li
+1 as author. There is an IPR filing on this technology, specifying the “don’t sue us, we won’t sue you” language. See https://datatracker.ietf.org/ipr/3361/ We are very interested in moving forward together on this work. Regards, Tony > On Feb 11,

Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

2019-02-01 Thread Tony Li
+1 Tony > On Feb 1, 2019, at 5:18 AM, John E Drake wrote: > > Chris & Acee, > > This looks fine to me. > > Yours Irrespectively, > > John > >> -Original Message- >> From: Lsr On Behalf Of Christian Hopps >> Sent: Friday, February 1, 2019 7:26 AM >> To: lsr@ietf.org >> Cc:

Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

2019-02-03 Thread tony . li
I think that this discussion would be greatly clarified if we clearly separated the discussion between a) the algorithm for computing the flooding topology, and b) the signaling to indicate how to proceed. I think that we are all in agreement that the algorithms can and should be separated

Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

2019-04-10 Thread tony . li
on B) is that the > algorithm/procedure is triggered by two or more failures happening at almost > the same time. Option B is the one described above. Option A seems simpler. > It fix the FT split by two or more failures. But for one failure, its work > may not be needed. > &g

Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

2019-04-15 Thread tony . li
Hi Huaimo, > Consider the case that the multiple failures occur at almost the same time > and there is no other failure following these multiple failures shortly. In > this case, the backup paths will connect the live end nodes of the failures > on the FT, and the FT partition is fixed. Note

Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

2019-04-13 Thread tony . li
Hi guys, I think that there’s some confusion here. > 1) The alternate backup path would appear to also require the criteria > of being link diverse with the FT if the goal is to protect against multiple > failures. > > [HC]: Can you give some more details about this? I think that

Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

2019-04-13 Thread tony . li
Hi Huaimo, > Computing a whole backup path between two end nodes of a failure and enabling > temporary flooding at each hop of the path will guarantee that these two end > nodes are connected on the FT, thus the FT partition caused by multiple > failures is fixed. The backup path is not a

Re: [Lsr] Enhancement related to Area Leader Sub-TLV

2019-05-24 Thread tony . li
Hi Huaimo, Thank you for your proposal. The area leader sub-tlv is only advertised by systems that are willing to be area leader. Presumably, that’s not necessarily all of the ones who support dynamic flooding. Thus, what you’re proposing moves one byte from one TLV into another TLV that

Re: [Lsr] Option B from "Migration between normal flooding and flooding reduction"

2019-05-26 Thread Tony Li
Hi Robert, > The current draft is pretty robust in terms of area leader election. It also > says that "Any node that is capable MAY advertise its eligibility to become > Area Leader” Correct. This can be all systems. It can be one. For redundancy, a few would be sensible. > With that

Re: [Lsr] Enhancement on LSDB re-synchronization in Flooding Reduction

2019-05-28 Thread tony . li
Hi Huaimo, > The current method: Whenever an existing link/adjacency L is added to the > flooding topology (FT for short), a full LSDB re-synchronization is requested > and executed over link L. Please recall that this is a set of CSNPs in IS-IS and a Database Summary in OSPF. Neither

Re: [Lsr] Enhancement related to Area Leader Sub-TLV

2019-05-29 Thread Tony Li
Hi Huaimo, > It seems that it is OK for only the leader advertises Area Leader sub-TLV. I disagree. Again, without other advertisements, the entire domain is at risk of losing the Area Leader and having an uncomfortable transition. > After the old/current leader is down, a new leader

Re: [Lsr] Enhancement related to Area Leader Sub-TLV

2019-05-28 Thread tony . li
Hi Huaimo, > Before moving, each of N nodes may advertise an Area Leader Sub-TLV and a > Dynamic Flooding Sub-TLV. After moving, only the leader node advertises a > (Updated) Area Leader Sub-TLV. The Area Leader sub-TLV should be advertised by all nodes that are candidates to being

Re: [Lsr] Enhancements on flooding topology encoding

2019-05-29 Thread tony . li
> A uses. > > From this example, we can see that C is more efficient than A and B, and > B is more efficient than A. > > Best Regards, > Huaimo > From: <> Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li > Sent: Wednesday, May 15, 2019 11:5

[Lsr] Fwd: New Version Notification for draft-li-lsr-isis-hierarchical-isis-01.txt

2019-06-05 Thread tony . li
internet-dra...@ietf.org > Subject: New Version Notification for > draft-li-lsr-isis-hierarchical-isis-01.txt > Date: June 5, 2019 at 1:13:07 PM PDT > To: "Paul Wells" , "Tony Li" , "Les > Ginsberg" > > > A new version of I-D, draft-li-lsr-

Re: [Lsr] IETF 105 LSR Working Slot Requests

2019-06-25 Thread Tony Li
Hi, I would like to request three slots: 1) Draft: draft-ietf-lsr-dynamic-flooding Speaker: TBD (put myself if you need a place holder) Duration: 5 mins Purpose: Update working group on interim meeting and progress 2) Draft: draft-li-lsr-area-abstraction Speaker: TBD

Re: [Lsr] WG Adoption Call: draft-ginsberg-lsr-isis-invalid-tlv

2019-06-12 Thread Tony Li
Support as co-author. I am not aware of any IPR. T On Wed, Jun 12, 2019 at 5:07 AM Peter Psenak wrote: > Hi Chris, > > I support the WG adoption of draft-ginsberg-lsr-isis-invalid-tlv. > > thanks, > Peter > > > On 12/06/2019 14:04, Christian Hopps wrote: > > This begins a 2 week WG adoption

Re: [Lsr] Flooding Negotiation bit

2019-05-14 Thread tony . li
Hi Huaimo, If I understand you correctly, this seems to have almost the same semantics as the Flooding Request TLV (section 5.1.5) or the Flooding Request Bit (section 5.2.7). If I’m not understanding you, could you please clarify the differences and why the current mechanisms are

Re: [Lsr] Migration between normal flooding and flooding reduction

2019-05-18 Thread tony . li
Hi Huaimo, Before we get into your procedure, I have to ask an important question: why is any process necessary? In our experience, It Just Works. You turn on dynamic flooding and the nodes with the feature start complying with the flooding topology. Those that are not enabled perform

Re: [Lsr] Migration between normal flooding and flooding reduction

2019-05-20 Thread tony . li
flooding, if we want to let the IGP on every node do flooding reduction some > time later, the procedure should be able to migrate from normal flooding to > the flooding reduction quickly and easily. > > Best Regards, > Huaimo > From: Tony Li [mailto:tony1ath...@gmail.com] On Be

Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

2019-04-29 Thread tony . li
Hi Huaimo, > You’ve computed the backup paths: [R4, R3, R6, R7] and [R5, R2, R9, R8]. > This results in enabling flooding on (R3, R6) and on (R5, R2), (R2, R9), (R9, > R8). > > [HC]: The enhanced algorithm enables the temporary flooding on (R3, R6) and > (R2, R9). It does not enable

Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

2019-04-19 Thread tony . li
Hi Huaimo, > I don’t think you can just assume that the network topology is not damaged in > some way. After all, the FT partitioned because of real failures. Your > algorithm for computing backup paths relies on old information about the > topology of other partitions. That information

Re: [Lsr] Fwd: Open issues with Dynamic Flooding

2019-04-10 Thread tony . li
Hi Dave, > So for my edification/education, this is a general behavior that in the > absence of any specific algorithm is postulated. (?) Yes. > The piece I do not quite get is "adding until fixed". Is the working > assumption that things have broken down to the point that there is no >

Re: [Lsr] Fwd: Open issues with Dynamic Flooding

2019-04-09 Thread tony . li
Hi Huaimo, >For "add temporary flooding in a rate limited manner", can you give some > details about how does the rate limit manner work for fixing a FT split? Nodes that have adjacencies that appear to be crossing the FT partition can enable temporary flooding on that circuit. This will

Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

2019-04-09 Thread tony . li
Hi Huaimo, Thank you for your discussion. Unfortunately, I (and apparently others) are still not following you. We need you to be very specific and explicit because if your algorithm is accepted, we must write code that implements it. It will not help interoperability if we have to guess

Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

2019-04-25 Thread tony . li
Hi Huaimo, > What is “the existing algorithm” that you have? > Is it the “rate limiting”? If so, can you describe the “rate limiting” > algorithm in details? Yes. We haven’t described it very formally, so let me see if I can be more precise: On each node, in parallel: On a

Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

2019-04-25 Thread tony . li
2, R9 and R8 and other nodes. > > The backup path for link R5-R8 is enabled for temporary flooding by R5,R2,R9 > and R8 (refer to Fig. 5). > > A unique backup path for link R4-R7, and a unique backup path for link R5-R8 > are computed and then enabled for temporary flood

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

2019-08-13 Thread tony . li
Robert, Thank you for your support. What would you suggest? Tony > On Aug 13, 2019, at 6:40 AM, Robert Raszuk wrote: > > Support. > > However assuming the draft will reach rough consensus of support I do > recommend to change the title during the conversion to WG document. ISIS is >

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

2019-08-16 Thread tony . li
Hi Aijun, Les kindly points out that what I’ve suggested here is completely non-standard and requires multiple IS-IS instances. Tony > On Aug 16, 2019, at 9:03 AM, tony...@tony.li wrote: > > Hi Aijun, > >> If, as you stated, we connect R1 and R7 via one link(although we will not >> do

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

2019-08-16 Thread tony . li
Hi Robert, > Of course the objective of the draft is clear and I do not think anyone is > questioning that. There was however topic of data and control plane > congruence requirement and I think we all agreed by now that this is rather > required in link state protocol as it is defined

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

2019-08-16 Thread tony . li
Hi Aijun, > If, as you stated, we connect R1 and R7 via one link(although we will not do > so, if we design the network hierarchically), how you flood the link > information hierarchically but let the traffic between the two connected L1 > area bypass the L2 area? The link between R1 and R7

Re: [Lsr] 答复: LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

2019-08-15 Thread tony . li
Hi Aijun, > 1. The size of network is increasing, but it is becoming more flat. Is it the > right direction to make the network more hierarchical? Well, given that we’re talking a link state protocol running SPF over a database in O(n log n) time, it’s pretty clear that we don’t want to

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

2019-08-15 Thread tony . li
Hi Robert, > > The hierarchical arrangement of the control plane does NOT imply that the > > data plane is necessarily hierarchical. > > Since Aijun posted his question I was trying to think of such model, but > failed. > > While it is easy to envision this with DV protocols say BGP - do

Re: [Lsr] IPR Poll for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

2019-08-12 Thread tony . li
I am not aware of any relevant IPR. Tony > On Aug 12, 2019, at 7:48 AM, Les Ginsberg (ginsberg) > wrote: > > I am not aware of any relevant IPR. > >Les > > From: Acee Lindem (acee) > Sent: Monday, August 12, 2019 7:36 AM > To: Tony Li mailto:t

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

2019-08-12 Thread tony . li
Support as co-author. T > On Aug 12, 2019, at 7:33 AM, Acee Lindem (acee) wrote: > > This begins a two week LSR Working Group Adoption Poll for the "Hierarchical > IS-IS" - draft-li-lsr-isis-hierarchical-isis-01. The poll will end at 12:00 > AM UTC on August 27th, 2019. Please indicate

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

2019-08-19 Thread tony . li
Hi Huaimo, > Support and have the following comments: Thank you for your support and comments. > It seems not necessary to have 8 levels of hierarchies. 3 or at most 4 levels > of hierarchies should be enough. IS-IS with 3 levels of hierarchies may > support a network with 1k*1k*1k nodes,

[Lsr] Fwd: New Version Notification for draft-dontula-lsr-yang-dynamic-flooding-00.txt

2019-09-04 Thread tony . li
ft-dontula-lsr-yang-dynamic-flooding-00.txt > Date: September 4, 2019 at 5:47:26 PM PDT > To: "Srinath Dontula" , "Tony Li" > > > A new version of I-D, draft-dontula-lsr-yang-dynamic-flooding-00.txt > has been successfully submitted by Tony Li and posted to th

Re: [Lsr] New Version Notification for draft-dontula-lsr-yang-dynamic-flooding-00.txt

2019-09-06 Thread tony . li
> > We welcome your comments. Please be gentle as we are YANG n00bs. > > Regards, > Srinath & Tony > > >> Begin forwarded message: >> >> From: internet-dra...@ietf.org >> Subject: New Version Notification for > draft-dontula-lsr-yang-dynamic

[Lsr] Dynamic flow control for flooding

2019-07-23 Thread Tony Li
Hi all, I’d like to continue the discussion that we left off with last night. The use case that I posited was a situation where we had 1000 LSPs to flood. This is an interesting case that can happen if there was a large network that partitioned and has now healed. All LSPs from the other side

Re: [Lsr] Dynamic flow control for flooding

2019-07-23 Thread tony . li
Hi Robert, > Are you working on the assumption that there is no data link layer flow > control already which could signal the OS congestion on the receiving end ? I am assuming that there is no link layer flow control. I can’t recall working on a system that supports X.25 since about

Re: [Lsr] Dynamic flow control for flooding

2019-07-24 Thread tony . li
Robert, Nothing has changed about the probability of network partitioning. That was simply a use case selected to motivate the discussion about flooding speed. The entire discussion is almost orthogonal to dynamic flooding. Let’s please take that out of the discussion. Tony > On Jul 24,

Re: [Lsr] Dynamic flow control for flooding

2019-07-24 Thread tony . li
Les, > Optimizing the throughput through a slow receiver is pretty low on my list > because the ROI is low. Ok, I disagree. The slow receiver is the critical path to convergence. Only when the slow receiver has absorbed all changes and SPFed do we have convergence. > First, the rate

Re: [Lsr] Dynamic flow control for flooding

2019-07-24 Thread tony . li
we (in decreasing order of importance): > > 1)Continue to flood fast to those nodes/links which can handle it > 2)Report the slow node to the operator (so they can address the limitation) > 3)Do what we can to limit the overload on the slow node/link > > Hope this helps.

Re: [Lsr] Dynamic flow control for flooding

2019-07-24 Thread tony . li
Robert, > The second part of the question was really about at what layer it makes most > sense to provide this control loop. To me, the obvious thing to do is to make minor revisions to the protocol. We need to: - Add a TLV so that the receiver can provide feedback. IMHO, this should be in

Re: [Lsr] Dynamic flow control for flooding

2019-07-24 Thread tony . li
> Whether a BCP draft is desired is something I am open to considering. Process nit: what we’re talking about doing, regardless of how we do it, is overriding 10589. As that’s a normative reference, overriding that requires that we have a standards track document. I don’t believe that even

Re: [Lsr] Dynamic flow control for flooding

2019-07-24 Thread tony . li
Les, > If you disagree please take things bullet-by-bullet: > > LSP input queue implementations are typically interface independent FIFOs Very true. It would not be unreasonable for an implementation to report free space in the FIFO (in number of PDUs) divided by the number of active

Re: [Lsr] Dynamic flow control for flooding

2019-07-24 Thread tony . li
Les, > This thread reminds me of how easy it is to miscommunicate – and I bear some > of the responsibility for that. Communications takes two. The receiver must also be focused on the input. My bad too. > I don’t see anything in there about changing the PSNP signaling rate. From >

  1   2   3   >