[Lsr] Re: Consensus Call on "IS-IS Distributed Flooding Reduction" - draft-ietf-lsr-distoptflood-05
option #2 On Monday, August 5, 2024 at 12:31:50 AM PDT, Peter Psenak wrote: Hi Acee, given that the flooding reduction algorithm can be used independently of the defined signaling (it can utilize the signaling defined in the dynamic flooding draft), option #2 make sense to me. thanks, Peter On 02/08/2024 20:06, Acee Lindem wrote: > The subject draft was adopted as a WG document containing only the flooding > reduction algorithm (section 2). > > Procedures and signaling have been added to the current version allowing > concurrent operation within an IS-IS area of IS-IS routers running different > flooding reduction algorithms or no flooding reduction at all (section 1). > > WG members are questioning if this extra requirement needs to be met and > included in this document. There was an extensive discussion during the IETF > 120 LSR meeting and a MeetEcho show-of-hands poll was taken - > https://notes.ietf.org/notes-ietf-120-lsr > > Please indicate your preference and reasoning amongst the following options > by August 17, 2024: > > 1) The document remains in its current form describing both the >flooding reduction algorithm signaling/procedures and the new flooding >reduction algorithm. > 2) The flooding reduction algorithm and procedures will be split into >a separate document with its own LSR WG adoption call. > 3) Some other resolution? > > Thanks, > Yingzhen, Chris, and Acee (LSR Chairs) > ___ > Lsr mailing list -- lsr@ietf.org > To unsubscribe send an email to lsr-le...@ietf.org > ___ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org ___ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)
Hi, As Les suggested in his email, below, I re-reviewed the first WG adoption thread and the delta between the version proposed for the first WG adoption and the version proposed for the second WG adoption, and I completely agree with him that this is a gratuitous and ill-advised change to the IGPs. The only reason advanced for its adoption, in either adoption call, is the groundless assertion that somehow it is a better way of identifying inter-AS links, which seems to be nonsense based upon the past thirty or more years of experience. Thanks, John On Monday, January 15, 2024 at 08:16:59 AM PST, Les Ginsberg (ginsberg) wrote: I respect that individuals may have different opinions - but it is important to distinguish what is factual from what is not. Opinions based upon false information are clearly compromised. Please do heed Chris's (as WG chair) admonition to review the first WG adoption thread. That will reveal to you what the substantive objections were. https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/ https://www.mail-archive.com/search?l=lsr%40ietf.org&q=stub+link&x=0&y=0 Please also do examine the delta between the previous version which was put up for WG adoption (V3) and the current version (V8) so you can see what has changed. https://author-tools.ietf.org/iddiff?url1=draft-wang-lsr-stub-link-attributes-03&url2=draft-wang-lsr-stub-link-attributes-08&difftype=--html Some facts: The substantive objections raised during the first adoption call had nothing to do with use cases - they had to do with: a)The use of a prefix to identify a link between two nodes is a flawed concept. It is not robust enough to be used in cases of unnumbered or Pt-2-MP. b)Existing mechanisms (RFC 9346/was RFC 5316 and RFC 5392) fully cover the potential use cases and do so more robustly than the Stub-link proposal. The latest version of the draft makes no substantive changes to the stub link concept or its advertisement. The only substantive change in the latest version is a reorganization of the presentation of use cases. But lack of clarity in the use cases was not the basis on which first WG adoption call was rejected. In this thread (the second WG adoption call), the authors have asserted that they have addressed the concerns raised in the previous adoption call. They have not. The concept and mechanism to identify a stub link has not changed. In this thread the authors continue to assert that RFC 9346/RFC 5392 cannot address the use cases. This is FALSE. As has been pointed out repeatedly, the existing mechanisms provide a robust means to uniquely identify inter-AS links using endpoint identifiers - be they IPv4/IPv6 addresses or Link IDs. This addresses all cases - numbered and unnumbered. There is therefore no need for a new mechanism. No fact-based argument has been made to justify reconsideration of WG adoption. I hope when people post their opinions, that they consider the facts. Les > -Original Message- > From: Lsr On Behalf Of Christian Hopps > Sent: Wednesday, January 10, 2024 2:17 AM > To: Huzhibo > Cc: Acee Lindem ; Yingzhen Qu > ; lsr@ietf.org > Subject: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes > (01/05/2024 - 01/19/2024) > > [As WG Co-Chair] > > Hi Folks, > > Before posting support reasons please read and considerl > *all* the email in the archive covering the first failed > adoption call. > > https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/ > https://www.mail- > archive.com/search?l=lsr%40ietf.org&q=stub+link&x=0&y=0 > > This adoption call should be considering if the changes > made to the document since it failed to be adopted the > first time, are sufficient to reverse the WGs previous > decision. > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)
I think Acee is correct On Monday, January 8, 2024 at 11:03:17 AM PST, Acee Lindem wrote: Speaking as WG member: I don’t support adoption of this draft. First of all, I think the basic premise of the draft is flawed in that a link is advertised as a stub and, from that, one can deduce uses of the link. Why not just advertise what is being deduced? Second, I don’t think the draft is necessary. The use case in A.1 is solely for an IGP router to advertise this stub link characteristic to a controller for inter-AS TE. Since it is only for the controller why wouldn’t be BGP-LS be used? It seems this is how it ultimately gets to the controller anyway. Furthermore, if it were to be put into the IGPs, why wouldn’t something like RFC 9346 be used for inter-AS TE? For the use case in A.2, anycast prefix advertisement is already handled and documents exist to identify a prefix as an anycast address. For the use case in A.3, I don’t even understand how it works or what is supposed to happen between BGP and the IGPs? What is different about this from normal BGP route recursion over the IGP route? For this, the fact that it is a stub link is irrelevant. Thanks,Acee On Jan 5, 2024, at 19:23, Yingzhen Qu wrote: Hi, This begins a 2 week WG Adoption Call for the following draft: https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/ Please indicate your support or objections by January 19th, 2024. Authors, please respond to the list indicating whether you are aware of any IPR that applies to the draft.*** Please note that this is the second WG adoption poll of the draft. The first one was tried two years ago and you can see the discussions in the archive:[Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 (ietf.org) Thanks,Yingzhen ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)
Hi, I prefer the term 'incremental deployment', i.e., everything works if you upgrade the network one node at a time. Irregardless, I think Les and others have done a good job of explaining why the subject draft is the best way forward for any number of reasons and I support its adoption. As is generally understood, flogging dead horses is counter-productive. Thanks, John On Friday, December 8, 2023 at 10:19:05 AM PST, Les Ginsberg (ginsberg) wrote: Huaimo – You don’t provide an operational definition of how to determine whether “all nodes need to have the same new information”, but it is easy to come up with cases where this is needed. Parag described one below and I have previously described one related to Flex Algo. I have yet to see you (or anyone else) present an example where “only the new nodes” need to use the additional information. But even if such examples exist, the logic required to determine this would be expensive and difficult to define in a robust way. And the state could change dynamically as sub-TLVs are added/removed. Deploying something that at best works some of the time is certain to lead to big problems. Our responsibility is to define robust solutions. Les From: Parag Kaneriya Sent: Friday, December 8, 2023 8:29 AM To: Huaimo Chen ; Les Ginsberg (ginsberg) ; li_zhenqi...@hotmail.com; Tony Li ; Linda Dunbar Cc: Yingzhen Qu ; draft-pkaneria-lsr-multi-...@ietf.org; lsr Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023) Legacy node gets half information result in the inconsistent view of network (for example TED [traffic engineering database] inconsistency lead to many network related issue.) hence legacy node getting half information is not backward consistent. Juniper Business Use Only From: Huaimo Chen Sent: Friday, December 8, 2023 7:23 PM To: Les Ginsberg (ginsberg) ;li_zhenqi...@hotmail.com; Tony Li ; Linda Dunbar Cc: Yingzhen Qu ;draft-pkaneria-lsr-multi-...@ietf.org; lsr Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023) [External Email. Be cautious of content] Hi Les, Your definition ofbackwards compatibility means that protocol extensions can be advertised and safely used in the presence of legacy nodes (which do not understand the new advertisements). Protocol extensions for Big-TLV include a new TLV (called container TLV) and a new Sub-TLV (called Big-TLV Capability Sub-TLV). Big-TLV is also short for Protocol extensions for Big-TLV. When adding a piece of new information into an existing TLV makes the TLV > 255, this new information can be put into a container TLV. The container TLV can be advertised in a network. The old/legacy nodes (i.e., the nodes not supporting Big-TLV) ignore the container TLV, which contains the new information. The new nodes (i.e., the nodes supporting Big-TLV) obtain the new information. Each of the new nodesadvertises a Big-TLV Capability Sub-TLV, indicating the capability of Big-TLV. The old/legacy nodes ignore it. The new nodes get it. If it is not required that all the nodes must have the same new information for using the new information, the new nodes can use the new information, the old/legacy nodes ignore the new information. If all the nodes need to have the same new information for using the new information, every node needs to check if all the nodes support the Big-TLV. If all the nodes support it, every node uses the new information. >From the above, we can see that “theprotocol extensions (: container TLV and >Big-TLV capability Sub-TLV, which is protocol extensions for Big-TLV) can be >advertised and safely used in the presence of legacy nodes (which do not >understand the new advertisements)”. The quoted is your definition of >backwards compatibility. So, the Big-TLV is backwards compatible. Best Regards, Huaimo From: Les Ginsberg (ginsberg) Sent: Thursday, December 7, 2023 1:07 PM To: Huaimo Chen ;li_zhenqi...@hotmail.com; Tony Li ; Linda Dunbar Cc: Yingzhen Qu ;draft-pkaneria-lsr-multi-...@ietf.org; lsr Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023) Huaimo – There are some things on which people can legitimately have different opinions – the meaning of backwards compatibility is not one of them. Your position seems to be that so long as I introduce a capability advertisement that controls whether a new advertisement is used when received that I can declare it “backwards compatible”. By that definition everything is “backwards compatible”. This makes the term “backwards compatibility” meaningless. This POV is neither useful nor sensible. Les From: Huaimo Chen Sent: Thursday, December 7, 2023 6:07 AM To: Les Ginsberg (ginsberg) ;li_zhenqi...@hotmail.com; Tony Li
Re: [Lsr] Technical questions for draft about unreachable prefixes announcement
Aijun, You castigated Peter for his lack of rigor in his reply to your email, however, I think that was completely unfounded. Further, your reply to Peter seems to be argument by emphatic assertion, rather than "technical analysis/comparison". Thanks, John On Monday, November 6, 2023 at 08:41:38 AM PST, Aijun Wang wrote: Hi, Peter: Let’s focus on the technical analysis/comparison for the mentioned issues, and don’t repeat the subjective comments that without any solid analysis. Detail replies inline below. Aijun WangChina Telecom On Nov 6, 2023, at 14:53, Peter Psenak wrote: Aijun, please see inline: On 06/11/2023 13:23, Aijun Wang wrote: Hi, all: Here are some technical questions for the hurry adopted draft about unreachable prefixes announcement: 1) There exists already “prefix originator” sub-TLV to indicate the associated prefix is unreachable, what’s the advantage of using other undefined, to-be-standardized, to-be-implemented sub-TLV? many people have already commented on why overloading the “prefix originator” sub-TLV to signal unreachability is a bad idea. Please accept that feedback. [WAJ] No one gives the technical analysis. Can you explain technically in detail? You can set the prefix metric to LS-infinity to indicate the unreachability, why can’t we the prefix originator to NULL to indicate the unreachability?———The key idea for using “prefix originator” is here: if there is no router originate the associated prefix, then it is certainly unreachable. It is more straightforward than the LS_Infinity, and is also more easily implemented, deployed than the to-be-defined, to-be-standardized sub-TLV. 2) It is unnecessary to define the “UP” flag——if the operator know the unreachable event in advance, they can also schedule the switchover of the related services in advance. Why bother IGP to transfer such information? looks like there are folks that see the value in it. I let them to comment more, but I don't necessarily see a problem in an extra bit. If you don't like it, don't use it. 3) There is very limited usage of LS_Infinity in current network. From the operator’s viewpoint, we will decrease its usage also in future. Then the solution should try their best to avoid their usages——Current solutions instead enhance its usage——It is unacceptable. Let’s keep the network simple. the reasons for using the LSInfinity for unreachability has been discussed at great length a;ready. It's the backward compatibility for routers not supporting the new signalling - we need to avoid them interpreting the unreachability as reachability. [WAJ] My emphasis is that we shouldn’t enhance the usage of LS-Infinity(you propose that the LS-Infinity metric must be carried) Instead, we should try to fade them out:1) If all routers within one area/domain all support the new capabilities, we need not require the summary LSA to carry LS-infinity metric. 2) The Maxage of LSA can also be used to achieve the similar effects of legacy node bypassing. 4) We can’t ignore the partitions scenarios or let’s it go. if you feel like the partition is the problem, you can write a separate draft and address it there. We are NOT trying to solve it with UPA draft. And for a reason. [WAJ] They are coupled. If you don’t consider it now, you need to update your proposal later. 5) There should be some mechanisms to control the volume of advertised unreachable information, when compared with reachable information, as done in https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-6. please look at the section 6 of the UPA draft. [WAJ] I am referring to the balance advertisement of reachable information, as did in the above link, not the simple statement as the following: “It is also recommended that implementations limit the number of UPA advertisements which can be originated at a given time. “ Actually, even for your above statement, https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#name-deployment-considerations-4 gives more guidelines, I think you can refer to it again. thanks, Peter Please consider the above technical issues carefully before evaluating and adopted any proposal. If the above issues can’t be solved, we request the WG to adopt also the https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/,which cover and solve all of the above issues. Aijun Wang China Telecom ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
