By this logic, when the Prefix Originator is set to 0.0.0.0, it means there is no Prefix Originator ... ;-)
Not sure why we are even arguing about this :-( On Wed, Nov 15, 2023 at 1:50 PM Aijun Wang <[email protected]> wrote: > Hi, Ketan: > > The logic is that why we can set router-id equal to 0.0.0.0 to indicate > some information in some standards, but we can’t set prefix originator > information to 0.0.0.0 to indicate the prefix is unreachable? > > Here are again two examples for the usages of router-id’s value as 0.0.0.0 > to indicate some information, one is for OSPF another is for IS-IS: > 1) For OSPF: https://www.rfc-editor.org/rfc/rfc5340.html#appendix-A.3.2 > > Designated Router ID > The sending router's view of the identity of the Designated Router for > this network. The Designated Router is identified by its Router ID. It is > set to 0.0.0.0 if there is no Designated Router. > > Backup Designated Router ID > The sending router's view of the identity of the Backup Designated Router > for this network. The Backup Designated Router is identified by its IP > Router ID. It is set to 0.0.0.0 if there is no Backup Designated Router. > > > 2) For IS-IS: https://www.rfc-editor.org/rfc/rfc7981.html#appendix-A > > If the originating node does not support IPv4, then the reserved value > 0.0.0.0 MUST be used in the Router ID field, and the IPv6 TE Router ID > sub-TLV [RFC5316 <https://www.rfc-editor.org/rfc/rfc5316>] MUST be present in > the TLV. > > > What I insist is that there are already containers that can be used to > indicate the unreachable information, why we pursue other non-existing, > non-standard container? > > Aijun Wang > China Telecom > > On Nov 7, 2023, at 18:16, Ketan Talaulikar <[email protected]> wrote: > > > Hi Aijun, > > I am not sure what "logic" you are looking for while being somewhat > dismissive of the arguments/logic provided. > > Let us agree to disagree. > > At least I've concluded that it is no more fruitful for me to try to > convince you. C'est la vie ... > > Thanks, > Ketan > > > On Tue, Nov 7, 2023 at 11:08 AM Aijun Wang <[email protected]> > wrote: > >> Hi, Ketan: >> >> There are many examples within IETF that special values has special >> meanings, please see: >> >> 1) >> https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml >> >> 2) >> https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml >> >> 3) >> https://www.iana.org/assignments/iana-as-numbers-special-registry/iana-as-numbers-special-registry.xhtml >> >> 4) LS-Infinity >> >> Then, please state clearly that why we cannot define specific value for >> prefix originator to indicate the unreachability. >> >> We need the logic that supports your conclusions. Until now, none. >> >> Or anyone else can elaborate the logic more clearly? >> >> Aijun Wang >> China Telecom >> >> On Nov 7, 2023, at 10:19, Ketan Talaulikar <[email protected]> wrote: >> >> >> 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 <[email protected]> >> 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= >>> [email protected]> wrote: >>> >>> >>> >>> Ketan – >>> >>> >>> >>> I am very happy to be wrong in this case. 😊 >>> >>> We are in full agreement. >>> >>> >>> >>> Les >>> >>> >>> >>> >>> >>> *From:* Lsr <[email protected]> *On Behalf Of * Ketan Talaulikar >>> *Sent:* Monday, November 6, 2023 11:52 PM >>> *To:* Les Ginsberg (ginsberg) <[email protected]> >>> *Cc:* John Drake <[email protected]>; Peter Psenak >>> (ppsenak) <[email protected]>; Aijun Wang <[email protected]>; >>> [email protected] >>> *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) < >>> [email protected]> 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 <[email protected]> *On Behalf Of *Ketan Talaulikar >>> *Sent:* Monday, November 6, 2023 3:01 PM >>> *To:* John Drake <[email protected]> >>> *Cc:* Peter Psenak (ppsenak) <[email protected]>; Aijun Wang < >>> [email protected]>; [email protected] >>> *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= >>> [email protected]> 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 < >>> [email protected]> 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 <[email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lsr >>> >>> _______________________________________________ >>> Lsr mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lsr >>> >>> _______________________________________________ >>> Lsr mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lsr >>> >>> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr >> >> _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
