[Lsr] Re: New Version Notification for draft-many-lsr-power-group-00.txt

Hi Gyan, Thank you for your comments. > This is an interesting idea and I support the concept of being able to > provide a TE cSPF constraint for KPI like power consumption based green > routing and power save idea to power down ports or components not in use. > > Great work. As this is

[Lsr] Re: New Version Notification for draft-many-lsr-power-group-00.txt

Hi Chris, >> Shutting down a link does not require centralized management action. It is >> quite sufficient to coordinate it between the routers on the ends of the >> link. >> >> Note that one can also conceive of a situation where there is a unilateral, >> ungraceful shutdown too. That req

[Lsr] Re: New Version Notification for draft-many-lsr-power-group-00.txt

Hi Robert, > If shutting down the link or lc requires some central management station it > does change the full design (perhaps simplifies it vastly) where all of the > optimizations can be centrally managed perhaps to varying degrees. Shutting down a link does not require centralized managem

[Lsr] Re: New Version Notification for draft-many-lsr-power-group-00.txt

Hi Robert, >> > "reduce the paths of the packets" - I meant to say reduce number of paths >> > (presumably TE end to end paths) the packets may take to traverse a domain >> > from ingress to egress. Apologies for the shortcut. >> >> If you’re asking if this changes the number of LSPs in the

[Lsr] Re: New Version Notification for draft-many-lsr-power-group-00.txt

Hi Robert, > "reduce the paths of the packets" - I meant to say reduce number of paths > (presumably TE end to end paths) the packets may take to traverse a domain > from ingress to egress. Apologies for the shortcut. If you’re asking if this changes the number of LSPs in the network, it do

[Lsr] Re: New Version Notification for draft-many-lsr-power-group-00.txt

Hi Robert, > Hmm so you are saying that you are proposing power optimisation architecture > without central controller which will have a global view of all demands in > the network and will reduce the paths of the packets ? No, there is no global view of all demands. We are working towards

[Lsr] Re: New Version Notification for draft-many-lsr-power-group-00.txt

Hi Robert, Thank you for your comments. > 1. Do we really see that carrying power consumption for the power groups is > something that belongs in link state protocol and flooded to all nodes vs > something that should be done with streaming telemetry to power optimizing > controller ? Yes

[Lsr] Re: New Version Notification for draft-many-lsr-power-group-00.txt

got our use cases from the Green WG and the > attendant metrics were derived from these use cases. > > I don't think we want a variety of point solutions - at least, we don't want > to start from there. > > Thanks, > Acee > >> On Aug 1, 2025, at 3:53 PM,

[Lsr] Re: New Version Notification for draft-many-lsr-power-group-00.txt

Hi Raul, > Yes, sorry, I had in mind the reverse approximation to the problem. > Indicating current power, power-save capability and current power-save status > (including interfaces) the resulting power-group hierarchy has enough > information and you don’t need calculations for the sleeping

[Lsr] Re: New Version Notification for draft-many-lsr-power-group-00.txt

Hi Raul, > While I see interesting to announce that a power group is power-save capable, > I would also see interesting the possibility to advertise that a power-group > is in fact in power-save mode. Announcing the capability could be useful for > external elements to later interact with the

[Lsr] Re: New Version Notification for draft-many-lsr-power-group-00.txt

> Juniper Business Use Only > From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> > mailto:internet-dra...@ietf.org>> > Sent: Wednesday, July 30, 2025 12:36 PM > To: Colby Barth mailto:cba...@juniper.net>>; Ron Bonica > mailto:rbon...@jun

[Lsr] Re: Obfuscated Terminology in "draft-ietf-lsr-isis-flood-reduction-arch-00"

To point 3: A component is a well known graph theoretic term: https://en.wikipedia.org/wiki/Component_(graph_theory) This is not 'invented'. This is a fundamental part of the technology that we work with. T On Tue, Jul 22, 2025 at 12:35 PM Acee Lindem - acee.lindem at gmail.com < mailforwa...@

[Lsr] Re: Review comments for draft-prz-lsr-hierarchical-snps-00: High Level Concerns

Les, [LES:] Let’s use a very simple example. A and B are neighbors For LSPs originated by Node C here is the current state of the LSPDB: A has (C.00-00(Seq 10), C.00-01(Seq 8), C-00.02(Seq 7) Merkle hash: 0xABCD B has (C.00-00(Seq 10), C.00-01(Seq 9), C-00.02(Seq 6) Merkle hash: 0xABCD (unlikel

[Lsr] Re: Review comments for draft-prz-lsr-hierarchical-snps-00: High Level Concerns

Hi Les, 1)The uniqueness of the calculated hash is an essential component for this to work. Given that you are using a simple XOR on a 64 bit number - and then "compressing" it to 32 bits for advertisement - uniqueness is NOT guaranteed. The danger of false positives (i.e., hashes that match w

[Lsr] Re: LSR WG Adoption Call on "An Algorithm for Computing Dynamic Flooding Topologies" - draft-chen-lsr-dynamic-flooding-algorithm-02

ng group chooses to do so"? > > I suggested it is published as one Information document if it is intended to > provide some information to the community. > > Best Regards > > Aijun Wang > China Telecom > > -Original Message- > From: Aijun Wang >

[Lsr] Re: IPR Poll WG adoption poll for "An Algorithm for Computing Dynamic Flooding Topologies" - draft-chen-lsr-dynamic-flooding-algorithm-02

Hi, All of the IPR that I am aware of has been disclosed already. Tony > On Jun 13, 2025, at 12:46 PM, Acee Lindem - acee.ietf at gmail.com > wrote: > > Co-authors, > > One IPR disclosure exists for this draft: > > > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-chen-ls

[Lsr] Re: LSR WG Adoption Call on "An Algorithm for Computing Dynamic Flooding Topologies" - draft-chen-lsr-dynamic-flooding-algorithm-02

Support, as co-author. T > On Jun 13, 2025, at 12:16 PM, Acee Lindem - acee.ietf at gmail.com > wrote: > > After some disruption, we are getting back to the normal work of the LSR > working group. > > This begins the start of a 3-week WG adoption poll for "An Algorithm for > Computing Dy

[Lsr] Re: WG Adoption Poll for "Flooding Reduction Algorithms Framework" - draft-prz-lsr-interop-flood-reduction-architecture-01

That is the way of the world. If you object to patent law, then I think you should take it up with appropriate lawyers… The IETF is hardly the appropriate venue. T > On Apr 28, 2025, at 1:04 PM, je_dr...@yahoo.com - je_drake=40yahoo.com at > dmarc.ietf.org wrote: > > What disturbs me is th

[Lsr] Re: WG Adoption Poll for "Flooding Reduction Algorithms Framework" - draft-prz-lsr-interop-flood-reduction-architecture-01

I support adoption. T > On Apr 27, 2025, at 7:39 AM, Acee Lindem - acee.ietf at gmail.com > wrote: > > LSR WG, > > This starts the Working Group adoption call for > draft-prz-lsr-interop-flood-reduction-architecture-01. Please send your > support or objection to this list before Monday,

[Lsr] Re: WG Last Call for draft-ietf-lsr-igp-ureach-prefix-announce (4/17/2025 - 5/2/2025)

Ok, I was simply trying to avoid beating a dead horse. Nothing about this discussion or this document is ’new’. I object because this information does not belong in the IGP. This is being used as a mechanism to propagate unreachabie more specifics. I grant that this is an important function f

[Lsr] Re: WG Last Call for draft-ietf-lsr-igp-ureach-prefix-announce (4/17/2025 - 5/2/2025)

I still object for the reasons that have been discussed. T > On Apr 17, 2025, at 11:13 AM, Yingzhen Qu - yingzhen.ietf at gmail.com > wrote: > > Hi, > > This email begins a 2 week WG Last Call for the following draft: > IGP Unreachable Prefix Announcement > https://datatracker.ietf.org/doc/

[Lsr] Re: Mohamed Boucadair's Yes on draft-ietf-lsr-multi-tlv-11: (with COMMENT)

Hi Robert, > Sorry if I was not very clear but my point was that MP-TLV may be coming in > multiple LSPs - something which to the best of my understanding is not the > case today with any TLV type. On that basis as LSP length natural boundary is > gone it seems sky is the limit now. This is

[Lsr] Opsdir telechat review of draft-ietf-lsr-ospf-prefix-extended-flags-06

Reviewer: Tony Li Review result: Has Nits OPSDIR Last Call Review of draft-ietf-lsr-ospf-prefix-extended-flags Reviewer: Tony Li Status: Has Nits Overall: Ready, but with a few nits. Details: Section 2: 1) OLD: This contains a variable number of 32-bit flags. NEW: This

[Lsr] Re: [Last-Call] 答复: Re: 【Can you concatenate several pieces together without one "explicit key" to identify them belong to the same segment】Re: Rtgdir last call review of draft-ietf-lsr-multi-tl

5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | 34 | Len = 4 | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | RESERVED| Ma

[Lsr] Re: [Last-Call] 答复: Re: 【Can you concatenate several pieces together without one "explicit key" to identify them belong to the same segment】Re: Rtgdir last call review of draft-ietf-lsr-multi-tl

other hand seems at odds with the last comment from Les ... > > "Breaking of a single sub-TLV or other data >unit across TLVs MUST NOT be done.” > > > > On Fri, Feb 21, 2025 at 9:41 PM Tony Li <mailto:tony...@tony.li>> wrote: >> >> As Les’ example

[Lsr] Re: [Last-Call] 答复: Re: 【Can you concatenate several pieces together without one "explicit key" to identify them belong to the same segment】Re: Rtgdir last call review of draft-ietf-lsr-multi-tl

Robert, > So it was very clear that we MUST skip what we do not recognize :) I was not > sure if we should at that point bail out from further parsing of a given TLV > or trying next sub-TLV. I guess there is no mandate of that in the spec and > implementations should/may try to continue to p

[Lsr] Re: [Last-Call] 答复: Re: 【Can you concatenate several pieces together without one "explicit key" to identify them belong to the same segment】Re: Rtgdir last call review of draft-ietf-lsr-multi-tl

Hi Robert, > If a peer happens not to recognize content of a sub-TLV within the first or > N-th part of the multi part TLV what is the expected behaviour ... is it to > stop parsing any subsequent content of given MP-TLV or skip unrecognized > sub-TLV and keep trying to decode the rest of them

[Lsr] Re: draft-ietf-lsr-multi-tlv and key information

Hi Robert, > With that I recommend to look a bit broader and count how many robust, > scalable and production grade open source implementations have we seen of > ISIS when comparing with the very same of BGP. > > I will let the reader guess why it looks as it looks why it is so much >

[Lsr] Re: WG Adoption Poll for "An Algorithm for Computing Dynamic Flooding Topologies" - draft-chen-lsr-dynamic-flooding-algorithm-02

Support, as co-author. T > On Jan 28, 2025, at 11:59 AM, Acee Lindem - acee.ietf at gmail.com > wrote: > > > The begins the LSR WG adoption call for "An Algorithm for Computing Dynamic > Flooding Topologies" - draft-chen-lsr-dynamic-flooding-algorithm-02. Please > express your support or

[Lsr] Re: WG Adoption IPR Poll for " An Algorithm for Computing Dynamic Flooding Topologies" - draft-chen-lsr-dynamic-flooding-algorithm-02

Hi Acee, All IPR that I am aware of has been disclosed in conformance with IETF rules. Regards, T > On Jan 28, 2025, at 11:50 AM, Acee Lindem - acee.lindem at gmail.com > wrote: > > Co-Authors, > > One IPR disclosure exists for this draft: > > https://datatracker.ietf.org/ipr/search/?sub

[Lsr] Re: Another counter-example

Les, > You assume that the understanding of the realities of “blast radius” by all > parties is accurate and correct. I believe this still requires examination > i.e., that the actual “blast radius” associated with leader-based when > implemented correctly is not inevitably global. The p

[Lsr] Re: Another counter-example

Hi Peter, > One can migrate from one algo to the other without reverting to the full > flooding using the leader announced algo. > Perhaps you missed the numerous operators who have requested a leaderless approach that limited the blast radius. Acee started a consensus check here: https://

[Lsr] Re: Another counter-example

upports algorithm Y and doesn’t understand algorithm X. > Flooding issues are notoriously difficult to diagnose – even when all nodes > are supposed to be doing the same thing. > All the while our mutual customer is (rightfully) pressuring to get this > fixed ASAP. > We might well

[Lsr] Re: Another counter-example

t; From: Tony Przygienda > Sent: Wednesday, December 4, 2024 12:35 AM > To: Peter Psenak (ppsenak) > Cc: Shraddha Hegde ; Robert Raszuk ; > Tony Li ; lsr > Subject: [Lsr] Re: Another counter-example > > Valid point of view but there are other solutions possible to the whole thi

[Lsr] Re: Another counter-example

Hi Tony, > A prunner MUST build CDS only within its component, i.e. algorithm X will > only optimize the A1/B1/A2/B2 component and cannot start to "decide about > other parts of the network" like assuming what Y will do or tell nodes in Y > what to do. This would amount to give a simile somet

[Lsr] Another counter-example

Hi all, Here’s another counter example. As with the previous one, the network has two portions: A and B. Subnetwork A has nodes A1, A2, A3, A4, ... and subnetwork B has nodes B1, B2, B3, B4, …. Nodes A1, A2, B1, and B2 are running algorithm X. They collectively decide that flooding betw

[Lsr] Re: A counter example

Hi Tony, > 2) if 2 algorithms are running and the minimal cut between their components > is 1 link this is only possible if the graph already had the articulation. If > you have more than one link between component X and Y the prunner framework > says that the link must be _always_ flooded so

[Lsr] Re: A counter example

lure – and this single link actually fails. How long would > it take for a typical implementation to set up the new, fixed flooding graph? > > Best regards, Martin > > Von: Tony Li mailto:tony1ath...@gmail.com>> > Datum: Montag, 25. November 2024 um 17:06 > An: Tony Przygie

[Lsr] Re: A counter example

Hi Robert, > > If your skepticism reaches to the centralized flooding topology algorithm > > It was the above. Ok. I think it would be very helpful to be very clear about these things, as there is some confusion. Our primary discussion has been about leader election vs. leaderless. > I

[Lsr] Re: A counter example

Hi Robert, > ** I am very sceptical that the leader from vendor X will always work > smoothly with all boxes from vendors Y, Z, W, Q … Again, leader election is derived from DIS election, so this begs the question: are you skeptical of DIS election? Do you have interoperable IS-IS on LANs

[Lsr] Re: A counter example

I wasn't specific enough when I said that I don't see a counter > example for -prz- framework not being correct. By correctness I always meant > "any mix of algorithms being prunners in a network will always deliver > _sufficient_ flooding" and not implied any kind o

[Lsr] Re: 答复: 答复: Consensus Call on LSR WG work on "Leaderless Flooding Algorithm for Distributed Flood Reduction to allow reduced configuration, minimal blast radius, and ease of incremental deployme

Hi Xiaohu, I think we all would agree on wanting things to be simple and this being LSR, we will all agree that IS-IS and OSPF are the right answer. ;-) However, there are some downsides to using a reflector for flooding. The first is convergence time. Even in optimal conditions, you're suggesti

[Lsr] A counter example

Hi all, Tony P. asked for a counter-example to why neighbor-only algorithm information is sufficient. This email attempts to articulate just such an example. Suppose that we have a bi-partite network, with two halves, A and B. Part A contains nodes A1, A2, A3, …. Part B contains nodes B1, B2

[Lsr] Re: Consensus Call on LSR WG work on "Leaderless Flooding Algorithm for Distributed Flood Reduction to allow reduced configuration, minimal blast radius, and ease of incremental deployment"

Hi Tony, > otherwise yes, people can have different preferred ponies based on the > requirements driving their topology/solution space and that speaks for > relevance of different algorithms and/or signalling approaches. But to be > precise, it does not necessarily imply that people or the W

[Lsr] Re: Consensus Call on LSR WG work on "Leaderless Flooding Algorithm for Distributed Flood Reduction to allow reduced configuration, minimal blast radius, and ease of incremental deployment"

Hi Gunter, I would like to counteract some of the Fear, Uncertainty, and Doubt that has misled you: > Some concerns I see with a flooding leader approach: > Single Point of Failure (the flooding leader becomes a critical component in > the network. If the leader fails or becomes unreachable,

[Lsr] Re: Consensus Call on LSR WG work on "Leaderless Flooding Algorithm for Distributed Flood Reduction to allow reduced configuration, minimal blast radius, and ease of incremental deployment"

Hi Tony, Please see inline. I’ve taken the liberty of reordering issues. > As to "optimal" flooding reduction, this is largely a rathole IMO. Any CDS > will basically generate the same amount of copies (which is what we optimize > for primarily IMO) and arguing that a certain CDS is better t

[Lsr] Re: Consensus Call on LSR WG work on "Leaderless Flooding Algorithm for Distributed Flood Reduction to allow reduced configuration, minimal blast radius, and ease of incremental deployment"

I support working on leaderless election. I’m a bit confused, because I don’t think that’s really the question at issue. The first question was whether leaderless election (other than ubiquitous configuration) can even work, given arbitrary algorithms. Computing a flooding topology is a glob

[Lsr] Re: Regarding the TE application question on draft-rigatoni-lsr-isis-fragment-timestamping

Hi Bruno, I haven't seen a reply from Pavan, so let me jump in... > > I can give a simple distributed TE application example (there are several, > but this should give a general idea how this information can be leveraged). > In RSVP-TE networks, a TE path computed using a specific snapshot of TED

[Lsr] Re: Comments on draft-ietf-lsr-distoptflood-07

> > >> If you want 'leaderless' then you simply remove the current discussion >> from the algorithm draft and only support manual, ubiquitous configuration >> in your implementation. >> > > Could you kindly quote which specific text in the version 07 are you > referring to ? > Please see figure 2.

[Lsr] Re: Comments on draft-ietf-lsr-distoptflood-07

Srihari, Enablement methodologies are independent of the algorithms which may be > enabled, and algorithms are independent of the method used to enable them. > > > > > *Srihari2> This is the disconnect. What if they are dependent ? Pls see my > comment below.* > > They are not dependent. That muc

[Lsr] Re: Comments on draft-ietf-lsr-distoptflood-07

What next? Shall we remove DIS election from the protocol too? Area leader election is based on the same algorithm. Clearly that’s too dangerous.Just because a customer wants something doesn’t mean that it’s a good idea.I’m sorry, I object and stand with Les.Regards,TonyOn Nov 5, 2024, at 5:27 AM,

[Lsr] Re: It's time to find one general solution to Big-TLV problem Re: IETF 121 LSR Slot Requests

> Why are we having this discussion again ? Because we have one member who refuses to respect the rough consensus of the working group. I will not speculate on motivations, but none of the possibilities are good. This places the chairs in the difficult position of having to deal with a DoS

[Lsr] Re: It's time to find one general solution to Big-TLV problem Re: IETF 121 LSR Slot Requests

> On Oct 22, 2024, at 4:53 PM, Acee Lindem - acee.ietf at gmail.com > wrote: > > Since my implementation and deployment experience is primarily in OSPFv(2|3) > I’d appreciate those with more IS-IS experience (both implementation and > deployment) to chime in. I concur. T ___

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

t? And can operators > be sure that these implementations are interoperable? > > Best regards, > Jie > > From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of Tony Li > Sent: Thursday, September 12, 2024 10:19 PM > To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>&

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

ow the needs, maybe it is better to narrow > down the scope of this document and focus on the specification for a smaller > group of TLVs. > > Best regards, > Jie > > From: bruno.decra...@orange.com <mailto:bruno.decra...@orange.com> > [mailto:bruno.dec

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Hi Bruno, > [Bruno2] I agree that everyone should already want to interoperable. But the > unfortunate reality is that not everyone does. I believe that RC3107 is a > relatively well-known example: some implementors have deliberately not > implemented all (implicit) MUST at the cost of interop

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Hi Bruno, > I also want correctness and I’m fine with your definition of MUST. > The issue with current text in -05 is that everyone can do MUST and MUST NOT > and things may not work. e.g., one node is allowed to send MP-TLV for TLV 22 > whatever is configured by the network operator. If oth

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Hi Robert, > So why keep pretending that the spec wording is useful ? I would much better > see to state in the RFC that let's leave how the TLVs are filled to the > discretion of the implementation and move on ... Forget about any normative > language. The current language in the spec is exa

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Hi Robert, >> You do not make the network safer by mandate. You make it safer by writing >> more forgiving code. > > Hope you agree that above all you make network interop safer by writing > deterministic protocol specifications. No! I disagree completely. As soon as you make the specifi

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Hi Bruno, > > First off, link identifiers are a sore spot. Mistakes were made. However, we > have, after many tweaks, achieved interoperability in the field. > > We are now just trying to formally document how to extend this into the > MP-TLV space. We do not want to upset the delicate bal

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Hi Bruno, > As you know, there are several TLVs that have been MP-TLV for a very long > time (e.g. ROUTER CAPABILITY). Having these be MP is a practical operational > necessity already today. Disabling this on any node would likely break any > network that has some fairly common features (e.

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Hi Bruno, > I’m not asking for per-TLV controls. > I’m asking for REQUIRED “configuration controls to enable/disable generation > of MP-TLVs.” > > IOW > OLD: It is RECOMMENDED that implementations which support the sending of > MP-TLVs provide configuration controls to enable/disable genera

[Lsr] Re: 【Major Issues Unsolved】I-D Action: draft-ietf-lsr-multi-tlv-05.txt

ietf.org > <mailto:internet-dra...@ietf.org> > 发送时间: 2024年9月6日 1:57 > 收件人: i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org> > 抄送: lsr@ietf.org <mailto:lsr@ietf.org> > 主题: [Lsr] I-D Action: draft-ietf-lsr-multi-tlv-05.txt > > Internet-Draft draft-ietf-ls

[Lsr] Re: 答复: Re: 【Please Abandon this WGLC document】答复: Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Hi Aijun, Please see the IETF procedures for determining rough consensus. We do not need unanimity. AFAICT, this draft is currently opposed only by you and Bruno and supported by many others. You’re welcome to look at the proof yourself, it’s quite obvious. Please also review RFC 7154 while

[Lsr] Re: Consensus Call on "IS-IS Distributed Flooding Reduction" - draft-ietf-lsr-distoptflood-05

Hi Acee, I beg to differ. Without a consistent, uniform algorithm selection, havoc will necessarily ensue. The algorithm itself can be distributed. The decision of which algorithm to use cannot be inconsistent. For this reason, I oppose moving forward as the document currently stands. Tony

[Lsr] Re: Zaheduzzaman Sarker's No Objection on draft-ietf-lsr-labv-registration-03: (with COMMENT)

Hi Zaheduzzaman, Unfortunately, the authors of RFC 5029 left us no note as to their motivations. Regards, Tony > On Aug 8, 2024, at 12:43 AM, Zaheduzzaman Sarker via Datatracker > wrote: > > Zaheduzzaman Sarker has entered the following ballot position for > draft-ietf-lsr-labv-registration-

[Lsr] Re: Paul Wouters' No Objection on draft-ietf-lsr-labv-registration-03: (with COMMENT)

Hi Paul, First, allocating those code points would require an RFC. Thus, it has the same overhead as changing the registration procedure. Second, the result would be a range of uncoordinated code points, which is not what we’re after. We do want to register and have unique code points for e

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Hi Bruno, > > However, it is not the job of this draft to resolve existing problems in > every single TLV in IS-IS. > > I would argue that this is not an existing problem, but a new problem created > by this document. So it would seem fair for this document to address the > problems it cre

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Bruno, We agree that interoperability is paramount. However, it is not the job of this draft to resolve existing problems in every single TLV in IS-IS. If nothing else, that would turn this document into more of an encyclopedia than it already is. That is simply not practical and not in kee

[Lsr] Re: 答复: 【What's the reason to move forward this document to be published?】答复: I-D Action: draft-ietf-lsr-multi-tlv-03.txt

issue in one extensible manner. > > Best Regards > > Aijun Wang > China Telecom > > > -邮件原件- > 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 > Tony Li > 发送时间: 2024年8月5日 12:40 > 收件人: Aijun Wang > 抄送: lsr@ietf.org

[Lsr] Re: 答复: 【What's the reason to move forward this document to be published?】答复: I-D Action: draft-ietf-lsr-multi-tlv-03.txt

t-ietf-lsr-multi-tlv-03.txt > > Internet-Draft draft-ietf-lsr-multi-tlv-03.txt is now available. It is a work > item of the Link State Routing (LSR) WG of the IETF. > > Title: Multi-part TLVs in IS-IS > Authors: Parag Kaneriya >Tony Li >Antoni P

[Lsr] Fwd: New Version Notification for draft-ietf-lsr-labv-registration-03.txt

FYI… T > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-ietf-lsr-labv-registration-03.txt > Date: July 29, 2024 at 12:39:31 PM PDT > To: "Tony Li" > > A new version of Internet-Draft draft-ietf-lsr-l

[Lsr] Re: Roman Danyliw's No Objection on draft-ietf-lsr-labv-registration-02: (with COMMENT)

Hi Roman, Thank you for your comments. > ** Section 2 > > The registration procedure for the "IS-IS Neighbor Link-Attribute Bit > Values" registry is changed to be "Expert Review". General guidance > for the designated experts is defined in [RFC7370] and more specific > guidance can be

[Lsr] Re: [Proxy of LSA Originator]Re: About Premature aging of LSA and Purge LSA

Hi, I was going to stay out of this, but then you went and picked on me. > The links that you provided has no relation for the discussions of "proxy of > LSA originator". Would you like to provide other pointer to support Tony's > assertion? If you look back a few years, you will find the

[Lsr] Re: Opsdir last call review of draft-ietf-lsr-labv-registration-01

Sue, Glad you’re doing better. I’ve submitted this change as -02. Thank you! See you in Vancouver! T > On Jul 8, 2024, at 11:52 AM, Susan Hares wrote: > > Tony: > > This change is wonderful. Thank you for your patience regarding my response. > > Sue > &g

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Support, as co-author. I am unaware of any IPR that pertains to this document. T > On Jul 1, 2024, at 11:07 PM, Yingzhen Qu wrote: > > Hi, > > This email begins a 2 week WG Last Call for the following draft: > draft-ietf-lsr-multi-tlv-01 - Multi-part TLVs in IS-IS >

[Lsr] Re: Opsdir last call review of draft-ietf-lsr-labv-registration-01

> On Jun 26, 2024, at 4:51 AM, Susan Hares via Datatracker > wrote: > > Reviewer: Susan Hares > Review result: Has Nits > > Type of review: OPS-DIR > Editorial comments: none > > Process comments: Normally, it is useful to give some advice to the > designated > experts for the specific reg

[Lsr] Re: Shepherd review of draft-ietf-lsr-labv-registration

Done. Thank you for your suggestions. T > On Jun 7, 2024, at 11:28 AM, Yingzhen Qu wrote: > > Hi Tony, > > Thanks for working on this document. > > I have the following comments for you to consider: > The working group should be set to "LSR Working Group" instead of "Network > Working Gro

[Lsr] Re: WGLC for draft-ietf-lsr-labv-registration

Thank you for making this happen and proving that the IETF process is not wholly ossified. T > On Jun 7, 2024, at 9:52 AM, Yingzhen Qu wrote: > > Hi, > > The WGLC is now concluded. Thanks to everyone who reviewed and commented on > the draft. > > I'll upload my shepherd write-up, then sub

[Lsr] Re: WGLC for draft-ietf-lsr-labv-registration

Support, as author. T > On May 22, 2024, at 8:59 AM, Yingzhen Qu wrote: > > Hi, > > This email begins a 2 week WG Last Call for the following draft: > draft-ietf-lsr-labv-registration-00 - Revision to Registration Procedures for > IS-IS Neighbor Link-Attribute Bit Values >

[Lsr] Re: WG Adotpion call - draft-li-lsr-labv-registration (5/2/2024-5/16/2024)

Done. Can we please now progress the document? Thanks, Tony > On May 20, 2024, at 7:04 AM, Yingzhen Qu wrote: > > The adoption call is now concluded, and the draft is adopted. > > Authors, please publish the draft as draft-ietf-lsr-labv-registration. > > Thanks, > Yingzhen > > On Mon, May

Re: [Lsr] WG Adotpion call - draft-li-lsr-labv-registration (5/2/2024-5/16/2024)

As author, I support adoption. I am unaware of any undisclosed IPR. Tony > On May 2, 2024, at 7:35 AM, Yingzhen Qu wrote: > > Hi, > > This email begins a 2 week WG adoption poll for the following draft: > https://datatracker.ietf.org/doc/draft-li-lsr-labv-registration/ > > Please review

Re: [Lsr] New Version Notification for draft-li-lsr-labv-registration-00.txt

gt; This is a non-controversial administrative change - I see no reason why this > process need take longer than that. > > Tony - friendly suggestion to trigger momentum - update the draft based on > Chris's suggestion and ask for WG adoption. > > Les > > > >

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

Per Les’ requeest. Elapsed time: 3 mins. T > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-li-lsr-labv-registration-01.txt > Date: April 23, 2024 at 4:24:44 PM PDT > To: "Tony Li" > > A new vers

Re: [Lsr] New Version Notification for draft-li-lsr-labv-registration-00.txt

Fair point. I can live with that. T > On Apr 20, 2024, at 12:20 AM, Christian Hopps wrote: > > [as wg-member] > > Any reason not to use Expert Review? FWIW, this is the only registry for > IS-IS that doesn't. > > Thanks, > Chris. > > Tony Li wr

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

@ietf.org > Subject: New Version Notification for draft-li-lsr-labv-registration-00.txt > Date: April 19, 2024 at 10:39:21 AM PDT > To: "Tony Li" > > A new version of Internet-Draft draft-li-lsr-labv-registration-00.txt has been > successfully submitted by Tony Li and poste

Re: [Lsr] Gunter Van de Velde's No Objection on draft-ietf-lsr-dynamic-flooding-17: (with COMMENT)

Gunter, Thank you for your comments. Please see inline. > Thank you for the work put into this document. This document is a joy to read > and documents an elegant solution to a well known IGP problem problem space. Thank you. > 409Similarly, if additional redundancy is added to the

Re: [Lsr] Genart last call review of draft-ietf-lsr-dynamic-flooding-16

Hi Reese, Thank you for your comments. Please see inline. > Introduction: > "However it is very clear that using an Exterior Gateway Protocol as an IGP is > sub-optimal, if only due to the configuration overhead." To me, the "very > clear" and the "if only due" sound like they're contradicting

Re: [Lsr] Working Group Last Call IPR Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints"

I am unaware of any undisclosed IPR. T > On Feb 19, 2024, at 2:20 PM, Acee Lindem wrote: > > Co-Authors, > > Are you aware of any IPR that applies to > draft-ietf-lsr-flex-algo-bw-con-07.txt? > If so, has this IPR been disclosed in compliance with IETF IPR rules (see > RFCs 3979, 4879,

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

l" > , "Peter Psenak" , "Srinath > Dontula" , "Tony Li" > > A new version of Internet-Draft draft-ietf-lsr-dynamic-flooding-16.txt has > been successfully submitted by Tony Li and posted to the > IETF repository. > > Name: draft-

Re: [Lsr] AD review of draft-ietf-lsr-dynamic-flooding-14

Hi John, > You’re welcome and thank you for your careful reply, and also for the > additional polishing. I’ve just reviewed the diff, it looks good. Just a few > things to note in the revision, below. Thanks again for your comments. Please see inline. > ### Section 5.1.1 > > • 1-127:

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

ate: February 6, 2024 at 4:44:09 PM PST > To: "Huaimo Chen" , "Luay Jalil" > , "Peter Psenak" , "Srinath > Dontula" , "Tony Li" > > A new version of Internet-Draft draft-ietf-lsr-dynamic-flooding-15.txt has > been successfully subm

Re: [Lsr] AD review of draft-ietf-lsr-dynamic-flooding-14

John, Thank you for your fantastic comments. Please see inline. > +++ draft-ietf-lsr-dynamic-flooding-14-jgs-comments.txt 2024-01-24 > 07:16:47.0 -0500 > @@ -231,6 +231,10 @@ >The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >"SHOULD", "SHOULD NOT", "R

Re: [Lsr] Paul Wouters' Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS)

consistent state in short order. Regards, Tony > On Jan 21, 2024, at 5:52 PM, Paul Wouters wrote: > > > >> On Jan 21, 2024, at 20:45, Tony Li wrote: >> >>  >> >> Hi Paul, >> >> Already done. Please see -12. > > Thanks, I had

Re: [Lsr] Paul Wouters' Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS)

Hi Paul, Already done. Please see -12. Thanks, Tony > On Jan 21, 2024, at 4:48 PM, Paul Wouters wrote: > > These changes look fine to me. Please cut another draft and I will update my > ballot to No Objection. > > Paul > > > > On Tue, Jan 9, 2024 at

Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS and COMMENT)

Hi Roman, >>> -- What are the relevant pointers to IS-IS security considerations? >> >> >> AFAIK, there is no overall document for IS-IS’ security architecture. The >> only >> pointers I can suggest are to RFC 5304 and 5310. I will happily add >> references >> to these if folks feel that’s

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

Mishra" > , "Sarah Chen" , "Tony Li" > , "Vivek Ilangovan" > > A new version of Internet-Draft draft-ietf-lsr-isis-area-proxy-12.txt has been > successfully submitted by Tony Li and posted to the > IETF repository. > > Name: draft-iet

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

T > To: "Gyan S. Mishra" , "Gyan Mishra" > , "Sarah Chen" , "Tony Li" > , "Vivek Ilangovan" > > A new version of Internet-Draft draft-ietf-lsr-isis-area-proxy-11.txt has been > successfully submitted by Tony Li and posted to

Re: [Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-isis-area-proxy-10: (with COMMENT)

Hi Murray, Thank you for your comments. > -- > COMMENT: > -- > > Section 7 creates a registry whose policy is partly Expert Review, but doesn't > give any part

Re: [Lsr] Genart last call review of draft-ietf-lsr-isis-area-proxy-10

Hi Peter, Thank you for your comments. > Page 4, second paragraph, second sentence: change "MPLS based" to > "MPLS-based". Fixed > Page 4, section 1.1: in the text version that I read, the boilerplate contains > the link "(https://tools.ietf.org/html/bcp14)". While this is found as a > hype

  1   2   3   4   5   6   >