Re: [Lsr] I-D Action: draft-dontula-lsr-yang-dynamic-flooding-03.txt

2020-09-15 Thread tony . li
draft-dontula-lsr-yang-dynamic-flooding-03.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > >Title : YANG Data Model for Dynamic Flooding >Authors : Srinath Dontula >

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-09-07 Thread tony . li
Hi Bruno, > At this point, area proxy spec is clear with regards to nominal behavior. So > indeed we are discussing error handling / transitions. (and thank you for > considering those cases, much appreciated). > > From memory, my understanding is the area proxy nominal behaviour requires:

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-09-04 Thread tony . li
Hi Bruno, > “A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an > Outside Router. » > Agreed (so far) > > “A Level 2 LSP with a source system identifier that is found in the Level 1 > LSDB MUST NOT be flooded to an Outside Router.” > I’m not sure to agree. > If that

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-09-04 Thread tony . li
Hi Bruno, Thank you for your comments. > 1) > OLD: The >advertisement in the Proxy LSP informs the remainder of the network >that packets directed to the SID will be forwarded by one of the >Inside Edge Nodes and the Area SID will be consumed. > > NEW: > The >advertisement in

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-09-02 Thread tony . li
Hi Xueson, > My intension was not to talk about math/engineering/marketing or compare the > size of marketing department. Them are not relevant to this thread. You are the one who suggested we leave it up to the market… > I want to make clear about IETF process. In my understanding the

[Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-04.txt

2020-09-02 Thread tony . li
; Date: September 2, 2020 at 7:35:25 AM PDT > To: "Tony Li" , "Gyan S. Mishra" > , "Gyan Mishra" , > "Vivek Ilangovan" , "Sarah Chen" > > > A new version of I-D, draft-ietf-lsr-isis-area-proxy-04.txt > has been successfully s

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-09-02 Thread tony . li
Hi Huaimo, > It seems that splitting L1 area A1 into two L1 areas A11 and A12 cannot > be automated without people's planning. Some people need to spend their time > in deciding where is the boundary between the two areas and selecting a > router in the backbone domain for Attach bit for

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-09-01 Thread tony . li
Hi Huaimo, > Assume that a big L1 area (say Area A1) is connected to backbone domain. > Let us compare TTZ and Areas for scalability. > > Using TTZ, we need two steps below: > 1) configure a piece of Area A1, named P1, as a zone; and > 2) transfer P1 to a virtual node using

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-09-01 Thread tony . li
Hi Xuesong, > Apologies first if I have missed any history of this discussion. But I’m not > sure that we have to evaluate whether a method is “optimal” before WG > adoption. Why not adopt some alternative solutions and leave the choice to > industry/market? First off, this is engineering,

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-09-01 Thread tony . li
Hi Huaimo, > > The question I and others have asked is “what can we do with zones that > > cannot be done with areas?”. > [HC]: IS-IS TTZ or say Zone is one of a few drafts which > experiment/explore new ways for scalability. These new ways may be simpler > and have some other features.

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-08-27 Thread tony . li
Les, > The statement “the … Prefix SID does NOT have the semantics that we want and > causes deleterious side-effects” is FALSE. Ahem. I disagree. No need to be rude about it. > There is an alternative here: > > Given that there isn’t any defined use case for the Area Prefix/SID, you

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-08-27 Thread tony . li
Les, > [Les:] Thanx for clarifying this. A careful reading of the draft supports > what you say, but as this point could be easily overlooked it might be worth > emphasizing this in the draft. Noted and enhanced. > We do NOT require that the Area Leader candidates have identical >

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-08-26 Thread tony . li
Hi Les, > [Les:] Any one of the IERs can be elected Area Leader, therefore all of them > have to be configured with the Area Prefix and associated SID. The Area Leader may not be an IER. In fact, in an important use case for us, the area is a leaf-spine topology. The Area Leader is one of

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-08-26 Thread tony . li
Les, > As per the draft: > > Area Proxy TLV is advertised by IERs in their L2 LSP. > Area Proxy TLV is NOT advertised in the Proxy LSP. > So how do the OERs become aware of the > > “prefix and SID that represents the entirety of the Inside Area to the > Outside Area” > > ??? > > I

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-08-26 Thread tony . li
Hi Les, > You have chosen to assign a prefix as the “Area Destination”. Are you sure you have the right document? The word “Destination” does not appear anywhere within https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03

[Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-08-24 Thread tony . li
afts > directories. > This draft is a work item of the Link State Routing WG of the IETF. > >Title : Area Proxy for IS-IS >Authors : Tony Li > Sarah Chen > Vivek Ilangovan >

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

2020-08-20 Thread tony . li
I have reviewed the change in -10 and it seems fine to me. Objection withdrawn. I support publication. Tony > On Aug 17, 2020, at 4:47 PM, tony...@tony.li wrote: > > > >> This begins a 2 week WG Last Call, ending after September 1st, 2020, for >> draft-ietf-lsr-flex-algo >> >>

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

2020-08-18 Thread tony . li
Les, There is no TLV called the Min Unidirectional Link Delay. If the document had said “The min delay of the Min/Max Unidirectional Link Delay” then there would be no confusion. Instead, it is the sloppy writing of ignoring the full name of the TLV that has created ambiguity. Now, Peter

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

2020-08-18 Thread tony . li
Robert, Thank you, exactly. We just need a clarification of the document. I don’t understand why this is such a big deal. Tony > On Aug 18, 2020, at 9:22 AM, Robert Raszuk wrote: > > Les, > > I think this is not very obvious as Tony is pointing out. > > See RFC 8570 says: > >

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

2020-08-18 Thread tony . li
Hi Peter, > section 5.1 of the draft-ietf-lsr-flex-algo says: > > Min Unidirectional Link Delay as defined in [I-D.ietf-isis-te-app]. > > We explicitly say "Min Unidirectional Link Delay", so this cannot be mixed > with other delay values (max, average). The problem is that that does not

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

2020-08-17 Thread tony . li
> This begins a 2 week WG Last Call, ending after September 1st, 2020, for > draft-ietf-lsr-flex-algo > > https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/ Hi, I’d like to raise an objection. Recently, I requested (and I thought that Peter agreed to) a clarification of the Min

Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

2020-08-10 Thread tony . li
Hi Peter, The flex-algo draft mentions "Min Unidirectional Link Delay as defined in [RFC7810 ]". When reading RFC7810, I found two Sub-TLVs: 4.1. Unidirectional Link Delay Sub-TLV 4.2. Min/Max Unidirectional Link Delay Sub-TLV

Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

2020-08-10 Thread tony . li
Hi Peter, >> The flex-algo draft mentions "Min Unidirectional Link Delay as defined in >> [RFC7810 > >]". When reading RFC7810, I found two >> Sub-TLVs: >> 4.1. Unidirectional Link Delay Sub-TLV 4.2. Min/Max

Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

2020-08-07 Thread tony . li
Peter, >> . The existing description in section 5.1 indicate that legacy encoding >> (RFC7810 and RFC5305) is used for link attributes. That is not correct based >> upon section 11. To avoid ambiguity can an explicit reference be added for >> [I-D.ietf-isis-te-app]? > > > well, section

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-07 Thread Tony Li
Hi Les, > 1)Invent a new type of SID which is associated with an area. > In this case some variation of encodings defined in V2 of the draft are > appropriate. But these aren’t backward compatible, which operators clearly want. > 2)Use a reachable address to get to the area. That address

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-06 Thread Tony Li
Les, > Not sure why this needs to be explained. Because we are not communicating well. We are each making unstated assumptions that do not mesh. When we do not communicate, it’s time to double check the basics. > Whether you are doing label forwarding or IP forwarding, the path of the >

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-06 Thread Tony Li
Les, > There then remains the question as to whether the “Area Prefix” is anycast > or unicast i.e., is it common to all IERs or is it unique to whomever gets > elected Area Leader? > > Does it matter? We have no clear semantics for this prefix. A difference that > makes no difference is

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-05 Thread Tony Li
Les, > This would make the Area Prefix mandatory for Area Proxy, which is not > desired. We would prefer it to remain optional and thus part of the Area SID > sub-TLV. > > [Les2:] You can advertise the Area Prefix in an optional sub-TLV – just as > you did with the Area SID. That is what I

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-05 Thread Tony Li
Les, > a)Advertise the “Area Prefix” in the Area Proxy TLV – much as we do a > router-id today in the Router-ID TLV. This would make the Area Prefix mandatory for Area Proxy, which is not desired. We would prefer it to remain optional and thus part of the Area SID sub-TLV. > b)The

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-04 Thread Tony Li
Hi Bruno, > > [Bruno] Agreed so far. > Do we agree that draft-ietf-lsr-isis-area-proxy uses the SID/Label sub-TLV? > We both agree that this sub-TLV has no mention of the global flag nor the > routing algoto be used. So far, we do NOT have agreement on that. Your argument yesterday

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread tony . li
Hi Robert, > How about we first define an "Area Prefix" (IP address being a property of an > area) then assign SID to it ? That’s effectively what Bruno is proposing. It adds some additional configuration and management overhead. Do you think it’s worthwhile? > How odd it may sound I

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread tony . li
Hi Acee, > [Acee] I know you guys have all thought about this a lot more than myself. > However, I’d envisioned this new Area SID as taking one to the closest entry > to the abstracted area. The next SID in the stack would either take you to a > destination inside the area or would use the

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-07-31 Thread tony . li
the goal is to > improve interop with existing/legacy L2 nodes so this may be valuable in the > draft. This point could be pushed to a deployment consideration section if > you don’t want any impact on the protocol extension. > > Thanks, > --Bruno > > (*) Assuming th

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-07-30 Thread tony . li
Hi Bruno, Thank you for your comments. > On Jul 30, 2020, at 9:22 AM, bruno.decra...@orange.com wrote: > > Hi Tony, > > Thanks for the updated draft. > > “ The Area SID Sub-TLV allows the Area Leader to advertise a SID that >represents the entirety of the Inside Area to the Outside

[Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-07-25 Thread tony . li
> Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt > Date: July 25, 2020 at 6:46:05 PM PDT > To: "Vivek Ilangovan" , "Sarah Chen" > , "Gyan S. Mishra&quo

Re: [Lsr] Request WG adoption of TTZ

2020-07-17 Thread tony . li
Hi Huaimo, > > “reducing the service interruption, making operations to be simple, and > so on” > does not require introduction of zones. We can already do so using areas – > including merging/splitting of an area. > > [HC]: Smooth merging/splitting of an area seems not reduce the

Re: [Lsr] Request WG adoption of TTZ

2020-07-13 Thread Tony Li
Hi Huaimo, > 1). It seems that Area Proxy can not be amended to IS-IS TTZ. IS-IS TTZ > abstracts a zone to a single node. This abstraction is supported by the > extensions to IS-IS, and some of these extensions are not defined in Area > Proxy. For example, the extensions for the edge nodes

Re: [Lsr] Request WG adoption of TTZ

2020-07-13 Thread Tony Li
Hi Huaimo, > 1). It seems that Area Proxy can not be amended to IS-IS TTZ. I feel that this is somewhat imprecise. From my perspective, our attempts to collaborate have been hampered by governmental regulations that are wholly out of our control. The suggestions that I’ve made for

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt

2020-07-08 Thread tony . li
Hi Les, > Again, the subTLVs of the area proxy TLV are for the coordination of the > Inside Area. The Area Proxy TLV appears in the Inside Node’s normal LSP. > > The Proxy LSP is for informing the Outside Area. > > [Les:] Understood – but I do not see why this requires you to advertise the

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt

2020-07-08 Thread tony . li
Hi Les, > The new definitions in the latest version in the draft are very close to what > we discussed in the earlier thread – so this looks pretty good to me. Excellent, thanks. > I still have some concerns regarding the Area Segment SID. > You propose to advertise this in two places: >

Re: [Lsr] Request WG adoption of TTZ

2020-07-07 Thread tony . li
Hi Aijun, Subdividing an existing area is entirely possible with Area Proxy. You just have to split the area and then apply Area Proxy. ;-) Tony > On Jul 7, 2020, at 7:36 PM, Aijun Wang wrote: > > Hi, Les: > > Using TTZ to sub divide the existing area seems more attractive. It seems TTZ

Re: [Lsr] Request WG adoption of TTZ

2020-07-07 Thread Tony Li
Hi Huaimo, > 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: That’s an unfortunate assumption. We have not defined OSPF Area Proxy because

Re: [Lsr] Request WG adoption of TTZ

2020-07-07 Thread tony . li
>> 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. > > This strikes me as the important difference from area proxy.

[Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt

2020-07-07 Thread tony . li
> From: internet-dra...@ietf.org > Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt > Date: July 7, 2020 at 8:14:58 AM PDT > To: "Gyan Mishra" , "Vivek Ilangovan" > , "Sarah Chen" , "Tony Li" > , "Gyan S. Mis

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

2020-06-30 Thread tony . li
Hi all, The authors are on-board with this round of suggestions from Les. Could I get a review by one more of our Designated Experts before we update the draft? Thanks, Tony > On Jun 29, 2020, at 3:07 PM, Les Ginsberg (ginsberg) > wrote: > > Tony – > > Inline. &

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

2020-06-29 Thread tony . li
Hi Les, > On Jun 29, 2020, at 2:13 PM, Les Ginsberg (ginsberg) > wrote: > > Tony – > > OLD: > 1)Area Proxy Router Capability - sub-TLV of Router Capability TLV > > 2)Inside Node TLV - Top level TLV > > 3)Area Proxy TLV - Top Level TLV with optional sub-TLVs: >Sub-TLV Area Proxy

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

2020-06-29 Thread tony . li
Hi, The authors have conferred and we would like to propose the following changes: - The semantics of the Inside Node TLV will be folded into the Area Proxy TLV. - The Area Proxy TLV will have its scope expanded to include pseudonodes. - No change to the Area Segment SID TLV encoding.

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

2020-06-25 Thread tony . li
Hi Hannes, Thanks for your comments. We will propose an alternate encoding. Tony > On Jun 25, 2020, at 10:47 AM, Hannes Gredler wrote: > > Hi Tony, > > I do share Les’ concerns on burning top-level 8-bit code point space at this > point. > > At this point it is not me to judge wether

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

2020-06-25 Thread tony . li
Chris, Thank you for your comments. We will figure out how we would like to proceed. Thanks, Tony > On Jun 24, 2020, at 5:17 PM, Christian Hopps wrote: > > > >> On Jun 21, 2020, at 12:50 PM, tony...@tony.li wrote: >> >> >> Les, >> >>> We don’t have to resolve this now. >>> One of my

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

2020-06-21 Thread tony . li
Les, > We don’t have to resolve this now. > One of my motivations for sending this was related to Early Allocation of > code points. Since you have already asked once, I am assuming that if WG > adoption is achieved it will be swiftly followed by an early allocation > request – and as one of

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

2020-06-21 Thread tony . li
Hi Les, > I am not yet overly enthused about approaches which promote non-hierarchical > network architectures. But it seems clear that there is interest in deploying > non-hierarchical solutions and both drafts present solutions > which merit further evaluation. I think that there’s some

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

2020-06-20 Thread tony . li
Hi Les, > Putting the Inside Node TLV aside for the moment, it would seem to me to be > advantageous (in a modest way) to have all information relating to Area Proxy > contained in one advertisement. Using Router Capabilities TLV would > accomplish that. I agree that the information should

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

2020-06-20 Thread tony . li
Hi Les, Thank you for your comments. Please see my comments inline. > draft-li-lsr-isis-area-proxy-06 currently proposes the use of one new > sub-TLV of Router Capabilities TLV and three new top level TLVs It should probably be noted that the Area Segment SID is somewhat orthogonal to

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-15 Thread tony . li
Tony, > If we rely on controller fixing LPM as well under failures then really, who > needs IGPs anymore anyway except for bunch of loopbacks and SPF for the > controller to do all the FIB work and hence discussions like high hierarchies > or anisotropic routing are largely superfluous me

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-15 Thread tony . li
> On Jun 15, 2020, at 10:56 AM, Tony Przygienda wrote: > > PNNI had transit areas in hierarchy working but the trick was connection > setup cranck-back. Such a thing would work for RSVP or any of the stateful > connection setups but alas, this is not fashionable right now. Unfortunately, >

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-15 Thread tony . li
Hi Robert, > > It’s very clear that this is inadequate. > > Doesn't this really depend how you architect multiple levels ? Sure you have > some physical topology - but it seems to me that the trick is in properly > laying out levels on top of them and between them. The very pragmatic

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-15 Thread tony . li
Hi Henk, > It's not so clear to me, sorry. > Does anyone have an example (link or jpg) of a (sensible) topology > that would not work with multiple levels of hierarchy, but works > nicely/better with area-proxies (or FRs) ? Just curious. Certainly. Draw a 3x3 grid with nodes at each

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-15 Thread tony . li
> On Jun 15, 2020, at 3:45 AM, Henk Smit wrote: > > BTW, personally I think the proper solution to scale IS-IS to larger > networks is 8 levels of hierarchy. Too bad that idea gets so little > push from vendors and operators. Hi Henk, It’s very clear that this is inadequate. The structure

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

2020-06-10 Thread tony . li
> Authors, please respond to the list indicating whether you are aware of any > IPR that applies to this draft. I am not a lawyer nor an author, but the area proxy IPR filing (https://datatracker.ietf.org/ipr/4016/ ) may also apply to this draft.

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-10 Thread Tony Li
> On Jun 10, 2020, at 12:27 PM, Christian Hopps wrote: > > This begins a 2 week WG adoption call for the following draft: > > https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/ > > The draft would be adopted on the Experimental track. > > Please indicate your support or

Re: [Lsr] Thoughts on the area proxy and flood reflector drafts.

2020-06-10 Thread tony . li
Tony, > On Jun 10, 2020, at 9:40 AM, Tony Przygienda wrote: > > You do seem to be carrying as WG member a hot torch for area-proxy for some > reason, that's fine with me, frankly, I had extensive discussions with > customers when DriveNet was being proposed to them (which AFAIS is basically

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

2020-06-05 Thread tony . li
Hi, > I have a question regarding the draft. At the end of section 3, it says if > there is any change in the base topology, the flooding topology MUST be > re-computed. So in case of a link failure in the base topo, it’s possible > that the link is not part of the flooding topology (e.g.

[Lsr] Request for Working Group Adoption: Area Proxy

2020-06-04 Thread tony . li
Dear Gentlebeings, I would like to formally request working group adoption of “Area Proxy for IS-IS” (https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03 ). The goal of this work is to improve scalability of IS-IS when

Re: [Lsr] Question on the early allocation - Re: [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04

2020-06-02 Thread tony . li
Hi Loa, > The code points are requested from "the IS-IS TLV Codepoints registry", > howver the "IS-IS TLV Codepoints" is a name space with 14 different > registries. I think the the registry you want to allocated code point > from the "TLV Codepoints registry” I apologize for the confusion,

Re: [Lsr] [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04

2020-06-01 Thread Tony Li
Hi Amanda, > However, the IANA Considerations section is missing some information. How > would we fill in the IIH, LSP, SNP, and Purge fields for the TLV Codepoint > registrations? We’ve addressed this in https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-06

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

2020-05-27 Thread tony . li
Les, > We are contemplating submitting a draft for this algorithm to the WG. We would welcome that. Does your algorithm have any relationship to https://tools.ietf.org/html/draft-allan-lsr-flooding-algorithm-00? >

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

2020-05-24 Thread tony . li
Hi Gyan, > Do you know if the dynamic flooding algorithm discussed during interim ietf > by Sarah and Toni is the same as the one implemented by Cisco on Nexus > platform or is Cisco’s Dynamic flooding a proprietary implementation? It appears not to be. Our algorithm is not limited to

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

2020-05-22 Thread tony . li
Hi Gyan, > I think with clos spine leaf the mesh is much more intensive and problematic > with ECMP then a circular topology nodal mesh that results in duplicate > redundant flooding that slows down convergence. With spine leaf it’s like an > X horizontal width axis and then depth is spine

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

2020-05-20 Thread tony . li
Hi Gyan, > This is a much needed feature that operators have been needing for densely > meshed topologies that commonly exist in data centers to accommodate very > high bandwidth E-W traffic. Thank you. > Please look at the feature description and it does seem to be exactly the > same as

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 IPR Poll

2020-05-18 Thread tony . li
> On May 15, 2020, at 12:47 PM, Acee Lindem (acee) > wrote: > > 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. > Hi,

Re: [Lsr] Questions about draft-ietf-lsr-dynamic-flooding-04

2020-05-11 Thread tony . li
Hi Xuesong, > Thank you for giving detailed proof, and it is very helpful to understand the > mechanism. > As I understand, it is showed in the proof that if there is proper temporary > flooding in R = E - E* - E’, same connectivity could be achieved by the > flooding topology F’ just as G’.

Re: [Lsr] Questions about draft-ietf-lsr-dynamic-flooding-04

2020-05-09 Thread tony . li
Hi Xuesong, > Thank you for your work about Flooding Reduction mechanism. I think it is > very useful for IGP scalability. Thank you, we very much appreciate that. > When Sarah giving presentation for > draft-chen-lsr-dynamic-flooding-algorithm-00 in LSR interim meeting, I raised > a

Re: [Lsr] Flooding across a network

2020-05-07 Thread tony . li
Les, > I have specifically used an example where “microloop avoidance” is not > applicable. So I did not want to use the term “microloop” but rather used > “loop” so as not to suggest that “microloop avoidance” is a potential > solution for the sub-optimal behavior. > Hope you can

Re: [Lsr] Congestion (flow) control thoughts.

2020-05-07 Thread tony . li
Hi Xuesong, > I agree that "minimal flooding time " is a good choice, which may differ from > the traditional cc in layer 4, which is difficult to get the completion time > for each flow. > I am still a little confused about " fast brand X needs to not overrun slow > brand Y while performing

Re: [Lsr] Congestion (flow) control thoughts.

2020-05-06 Thread tony . li
Hi Xuesong, > I think there is no need to distinguish the concept of flow control > and congestion control, considering that the core idea is the same: monitor > the sending rate to match the capability of the bottleneck, no matter there > are competitors or not. And the control loop is

Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough

2020-05-04 Thread tony . li
Mitchell, > I think we/you are looking at two different problems: > 1) a hop count of 1 or maybe two between the two end points 2) and the > multiple / many hop count between the two end points. IS-IS adjacencies are always between immediate L3 neighbors, ignoring

Re: [Lsr] Congestion (flow) control thoughts.

2020-04-30 Thread tony . li
Hi Xuesong, > In congestion control of layer 4, it is assumed that there is a bottleneck in > the network, and the ideal rate of the transmitters equals to a fair share of > the bandwidth in the bottleneck. The flows in the network change all the time > and so as to the ideal transmitting

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread tony . li
Robert, > Apologies if I missed it but so far I understood that the new signalling from > the receiver could be different per each LSP sender (per each Hello). Correct. We propose to piggyback feedback information in IIH’s, and *SNPs. > Above I am suggesting that such signalling to be

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread tony . li
Robert, > For per peer flow control I do not get how receiver's ISIS process is to come > up with per peer timer if it may never see under congestion given peer's LSPs > (being dropped on the single RE cp queue or at the interface). I’m sorry, but I can’t parse this comment. The intent is

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread tony . li
> If we have 1000 of interfaces and all peers *all in the same time* will send > us an LSP of max size of 1492 octets that our control plane buffer RAM size > required to store them would be as huge as 1.5 MB. And that assumes we did > not process any from arrival of the first to the arrival

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread tony . li
Hi Robert, > Today from what I see operators (if they even change the default) normally > apply same timer value on all interfaces. If the timer is static what would > be the incentive for any implementation not to group interfaces with > identical transmit delay ? Why should the timer be

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread tony . li
Robert, > > In both cases, this call, IMO a signaling capability from the receiver to > > the sender. > > So essentially you are asking for per peer flooding queue. You already have a per-interface flooding ‘queue' through the implementation of the SRM bit in the LSDB, which must be

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed -- A plea for cooperation

2020-04-20 Thread tony . li
Gentlebeings, This discussion is producing far more heat than light. Can we please refocus our attentions? I think that we all agree that the legacy parameters are no longer serving us well and that we need to reconsider our flooding parameters and mechanisms. If we fail to reach a

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-20 Thread tony . li
Bruno, > Waiting some more details, as per you below email, the IS-IS receiver does > have a queue, sometimes dedicated to IS-IS, but in general relatively > dedicated to very important and time sensitive traffic to the control plane. > Details are indeed implementation specific. But in

Re: [Lsr] I,Scope of FIT Capability: a node or a link?

2020-04-06 Thread Tony Li
> This discussion is interesting, but please do not ignore the considerable > feedback from multiple folks indicating that this advertisement does not > belong in the IGP at all (regardless of scope). > My opinion on that has not changed. +1 IS-IS is not the correct place to implement

Re: [Lsr] Dynamic flooding path computation

2020-04-03 Thread tony . li
Hi Peter, > it may be worth to make your algorithm one of the standardized distributed > algorithms. There might be some work to make it deterministic, like the > selection rules mentioned below, but it should be doable. > > What do you think? I will certainly stipulate the possibility.

Re: [Lsr] On collaboration for abstraction

2020-04-03 Thread tony . li
Hi Alvaro, > Having official and open meetings is the way to go. I concur. > An alternative would be for the group to work as a Design Team: the > discussions can happen in the lsr list, periodic open calls can be > scheduled...without some of the administrative overhead. The DT could

[Lsr] Dynamic flooding path computation

2020-04-02 Thread tony . li
Hi, In this morning’s session, Acee asked a question about node selection as part of path computation. I would like to expound a bit in the spirit of full transparency. First off, the selection of nodes is NOT vital to the algorithm. That said, we found that applying some heuristics helped

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

2020-04-02 Thread tony . li
> Sure it is possible to discover if my tailends are capable of handling in > band telemetry by off line means. But what I am struggling to see why we > allowed so much TE stuff into IGPs and we do not want to make it easier for > headends to operate without PCE at all for the purpose of

[Lsr] On collaboration for abstraction

2020-04-02 Thread tony . li
Hi, I’d like to comment on the process for moving forward for the abstraction proposals that we are discussing (TTZ, Area proxy, flooding reduction, …). My understanding of the block on collaboration is that we are prohibited from collaborating privately. We MAY have open, public

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

2020-03-03 Thread tony . li
. Regards, Sarah & Tony > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for > draft-chen-lsr-dynamic-flooding-algorithm-00.txt > Date: March 3, 2020 at 10:16:37 AM PST > To: "Yunxia Chen" , "Tony Li" ,

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-02-20 Thread Tony Li
Les, > With respect, it is hard to know what you are proposing since there has never > been a public description. With respect, I’ve said it many times, both in person and in email. You need to hear it again? Sure. > The draft on which you are a co-author does not discuss any sort of

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-02-19 Thread tony . li
> easy to say with a single PD. If you have 20, each with a different > architecture, it becomes a different problem. My employer has multiple PD implementations. I sympathize, but it’s still necessary. Tony ___ Lsr mailing list Lsr@ietf.org

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-02-19 Thread tony . li
Les, > As you need to send signaling based upon dynamic receiver state and this > signaling is contained in unreliable PDUs (hellos) and to be useful this > signaling needs to be sent ASAP - you cannot wait until the next periodic > hello interval (default 10 seconds) to expire. So you are

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-02-19 Thread tony . li
Peter, > I'm not scared of polynomial evaluation, but the fact that my IGP > implementation is dependent on the PD specifics, which are not generally > available and need to be custom built for each PD specifically. I always > thought a good IGP implementation is PD agnostic. Your

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-02-19 Thread Tony Li
Peter, > I'm aware of the PD layer and that is not the issue. The problem is that > there is no common value to report across different PD layers, as each > architecture may have different number of queues involved, etc. Trying to > find a common value to report to IPGs across various PDs

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-02-19 Thread Tony Li
Peter, > Given many different hardware architectures one may run a single IGP > implementation on, this becomes impractical and complex as each hardware > architecture has its own specifics. One would rather keep the IGP > implementation hardware agnostic, rather than providing hardware

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-02-19 Thread Tony Li
Peter, > above is nowhere close to what the reality is, especially in the distributed > system. In such system, packets traverses via multiple queues on both LC and > RP and application like IGP has no visibility to these queues. As you may recall, I was lead software architect for NCS

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-02-18 Thread tony . li
Les, > Overall, I think you are making general statements and not providing needed > specifics. I’m sorry it’s not specific enough for you. I’m not sure that I can help to your satisfaction. > Maybe it’s obvious to you how a receiver based window would be calculated – > but it isn’t

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-02-18 Thread tony . li
Les, > Then the LSP transmitter is operating without information from the LSP > receiver. Additional information from the receiver can help the transmitter > maintain a more accurate picture of reality and adapt to it more quickly. > > [Les:] This is your claim – but you have not provided

  1   2   3   >