Hi Aijun, I realize that continuing this argument with you is futile.
However, perhaps one last response that I would address not to you but for other WG members (if any one is still following this thread). On Tue, Nov 7, 2023 at 9:54 AM Aijun Wang <wangai...@tsinghua.org.cn> wrote: > Hi, Ketan and Les: > > There are two sub-TLVs to indicate the source information of the prefix > within OSPF——“Prefix Source OSPF Router ID” and “Prefix Source OSPF Router > Address” > > What’s you refer to is the first sub-TLV, for the second sub-TLV, we > haven’t such statements, this is also true for IS-IS, as Les pointed out. > KT> I am not a lawyer. The semantics for Prefix Source OSPF Router Address should be clear to anyone that reads the procedures in Sec 3. > > > So, contrary to your happiness :) this give us the room to define the > specific value to indicate “unreachability”. > > And, to Ketan again, until now, you don’t explain clearly that if we can’t > define specific value for “unreachability” why can we define the specific > value for “LS-Infinity”? > KT> For LS-Infinity - please read RFC2328. Thanks, Ketan > > > Aijun Wang > China Telecom > > On Nov 7, 2023, at 09:23, Les Ginsberg (ginsberg) <ginsberg= > 40cisco....@dmarc.ietf.org> wrote: > > > > Ketan – > > > > I am very happy to be wrong in this case. 😊 > > We are in full agreement. > > > > Les > > > > > > *From:* Lsr <lsr-boun...@ietf.org> *On Behalf Of * Ketan Talaulikar > *Sent:* Monday, November 6, 2023 11:52 PM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* John Drake <je_drake=40yahoo....@dmarc.ietf.org>; Peter Psenak > (ppsenak) <ppse...@cisco.com>; Aijun Wang <wangai...@tsinghua.org.cn>; > lsr@ietf.org > *Subject:* Re: [Lsr] Technical questions for draft about unreachable > prefixes announcement > > > > Hi Les, > > > > I disagree with your reading of RFC9084 (OSPF Prefix Originator). > > > > Sec 1 > > This document proposes extensions to the OSPF protocol for the inclusion > of information associated with the router originating the prefix along with > the prefix advertisement. These extensions do not change the core OSPF > route computation functionality. > > > > Sec 2.1 > > For intra-area prefix advertisements, the Prefix Source OSPF Router-ID > Sub-TLV *MUST* be considered invalid and ignored if the OSPF Router ID > field is not the same as the Advertising Router field in the containing > LSA. Similar validation cannot be reliably performed for inter-area and > external prefix advertisements.¶ > <https://www.rfc-editor.org/rfc/rfc9084.html#section-2.1-6> > > A received Prefix Source OSPF Router-ID Sub-TLV with the OSPF Router ID > field set to 0 *MUST* be considered invalid and ignored. Additionally, > reception of such sub-TLVs *SHOULD* be logged as an error (subject to > rate limiting). > > As editor of this document, it is absolutely clear to me that we are > referring to the sub-TLV and not the prefix advertisement. So, when the > value is set to 0, the sub-TLV is invalid and ignored - the prefix > reachability is not at all affected. > > This is the reason why I am firmly opposed to using Prefix Originator > value 0 for UPA or any other indication. > > > > I hope I am able to convince you :-) > > > > Thanks, > > Ketan > > > > > > > > On Tue, Nov 7, 2023 at 12:44 AM Les Ginsberg (ginsberg) < > ginsb...@cisco.com> wrote: > > To add to what Ketan has stated… > > > > draft-wang-lsr-prefix-unreachable-annoucement defines the same mechanism > for both OSPF and IS-IS i.e., it proposes to use a prefix-originator > sub-TLV with address set to 0.0.0.0 to indicate unreachability. > > For OSPF, this might be considered compatible with RFC 9084 where it is > stated that advertisements with “Router ID field set to 0 MUST be > considered invalid and ignored” - though Ketan has indicated this usage is > undesirable. > > However, no equivalent statement was ever made for IS-IS in RFC 7794 – so > this simply does not work in the case of IS-IS. > > I (among others) pointed this out to the authors of draft-wang multiple > times over the years, but my feedback was ignored. > > > > Which is an example of why I would like to echo Ketan’s sentiments – let’s > please put an end to this non-constructive discussion. > > > > The authors of draft-wang have had many opportunities over the years to > respond in a more constructive way to feedback. They were also – as Peter > has indicated – given an opportunity to co-author > draft-ietf-lsr-igp-ureach-prefix-announce out of respect for them bringing > the problem space to the attention of the WG. They declined – which of > course is their right. But they do not have the right to endlessly oppose > the consensus of the WG. > > > > Let’s please move on. > > > > Les > > > > > > *From:* Lsr <lsr-boun...@ietf.org> *On Behalf Of *Ketan Talaulikar > *Sent:* Monday, November 6, 2023 3:01 PM > *To:* John Drake <je_drake=40yahoo....@dmarc.ietf.org> > *Cc:* Peter Psenak (ppsenak) <ppse...@cisco.com>; Aijun Wang < > wangai...@tsinghua.org.cn>; lsr@ietf.org > *Subject:* Re: [Lsr] Technical questions for draft about unreachable > prefixes announcement > > > > Hi Aijun, > > > > As your co-author on the OSPF Prefix Originator RFC, I have stated many > times (e.g. [1]) that overloading semantics of Prefix Originator is not a > good or clean protocol encoding. Semantically, it is wrong and a very bad > protocol design in my opinion. Going by this logic, tomorrow, someone would > want to encode some different meaning for all 1's value in the originator > address. We cannot be doing such (IMHO) HACKS in the protocol encodings. > > > > It is better to signal the semantics/meaning explicitly using specific > flags that are meaningful. > > > > The authors of draft-ppsenak (now a WG document) agreed to this feedback > from WG members and incorporated the U/UP flags in their draft. However, > the authors of draft-wang seem to continue to refuse to accept feedback. It > is perhaps one of the reasons why the WG adopted the draft-ppsenak and not > draft-wang. > > > > WG chairs, is there a way to put an end to this debate such that it does > not continue endlessly? > > > > Thanks, > > Ketan > > > > [1] thread > https://mailarchive.ietf.org/arch/msg/lsr/FNbqHPhphY3GOfw-NWkLjmoRDVs/ > > > > > > On Mon, Nov 6, 2023 at 7:31 PM John Drake <je_drake= > 40yahoo....@dmarc.ietf.org> wrote: > > 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 < > wangai...@tsinghua.org.cn> 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 Wang > > China Telecom > > > > On Nov 6, 2023, at 14:53, Peter Psenak <ppse...@cisco.com> 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 > > _______________________________________________ > 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