Re: [Lsr] Technical questions for draft about unreachable prefixes announcement
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 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 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 > 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 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 >> 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) >> 40cisco@dmarc.ietf.org> wrote: >>> >>> >
Re: [Lsr] Technical questions for draft about unreachable prefixes announcement
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.2Designated 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-AIf 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] 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 WangChina TelecomOn Nov 7, 2023, at 18:16, Ketan Talaulikar 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,KetanOn Tue, Nov 7, 2023 at 11:08 AM Aijun Wang <wangai...@tsinghua.org.cn> 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.xhtml2) https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml3) https://www.iana.org/assignments/iana-as-numbers-special-registry/iana-as-numbers-special-registry.xhtml4) LS-InfinityThen, 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 WangChina TelecomOn Nov 7, 2023, at 10:19, Ketan Talaulikar <ketant.i...@gmail.com> 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 <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 WangChina TelecomOn Nov 7, 2023, at 09:23, Les 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 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.¶ A received Prefix Source OSPF Router-ID Sub-TLV with the OSPF Router ID field set to 0 MUST be con
Re: [Lsr] Technical questions for draft about unreachable prefixes announcement
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 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 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 > 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) > 40cisco@dmarc.ietf.org> wrote: >> >> >> >> Ketan – >> >> >> >> I am very happy to be wrong in this case. >> >> We are in full agreement. >> >> >> >> Les >> >> >> >> >> >> *From:* Lsr *On Behalf Of * Ketan Talaulikar >> *Sent:* Monday, November 6, 2023 11:52 PM >> *To:* Les Ginsberg (ginsberg) >> *Cc:* John Drake ; Peter Psenak >> (ppsenak) ; Aijun Wang ; >> 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
Re: [Lsr] Technical questions for draft about unreachable prefixes announcement
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.xhtml2) https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml3) https://www.iana.org/assignments/iana-as-numbers-special-registry/iana-as-numbers-special-registry.xhtml4) LS-InfinityThen, 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 WangChina TelecomOn Nov 7, 2023, at 10:19, Ketan Talaulikar 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 <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 WangChina TelecomOn Nov 7, 2023, at 09:23, Les 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 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.¶ 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
Re: [Lsr] Technical questions for draft about unreachable prefixes announcement
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 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) 40cisco@dmarc.ietf.org> wrote: > > > > Ketan – > > > > I am very happy to be wrong in this case. > > We are in full agreement. > > > > Les > > > > > > *From:* Lsr *On Behalf Of * Ketan Talaulikar > *Sent:* Monday, November 6, 2023 11:52 PM > *To:* Les Ginsberg (ginsberg) > *Cc:* John Drake ; Peter Psenak > (ppsenak) ; Aijun Wang ; > 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
Re: [Lsr] Technical questions for draft about unreachable prefixes announcement
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. 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”?Aijun WangChina TelecomOn Nov 7, 2023, at 09:23, Les Ginsberg (ginsberg) wrote: Ketan – I am very happy to be wrong in this case. We are in full agreement. Les From: Lsr On Behalf Of Ketan Talaulikar Sent: Monday, November 6, 2023 11:52 PM To: Les Ginsberg (ginsberg) Cc: John Drake ; Peter Psenak (ppsenak) ; Aijun Wang ; 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.¶ 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 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 per
Re: [Lsr] Technical questions for draft about unreachable prefixes announcement
Ketan – I am very happy to be wrong in this case. We are in full agreement. Les From: Lsr On Behalf Of Ketan Talaulikar Sent: Monday, November 6, 2023 11:52 PM To: Les Ginsberg (ginsberg) Cc: John Drake ; Peter Psenak (ppsenak) ; Aijun Wang ; 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) mailto: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 mailto:lsr-boun...@ietf.org>> On Behalf Of Ketan Talaulikar Sent: Monday, November 6, 2023 3:01 PM To: John Drake mailto:40yahoo@dmarc.ietf.org>> Cc: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; Aijun Wang mailto:wangai...@tsinghua.org.cn>>; lsr@ietf.org<mailto: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 mailto: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/com
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) 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 *On Behalf Of * Ketan Talaulikar > *Sent:* Monday, November 6, 2023 3:01 PM > *To:* John Drake > *Cc:* Peter Psenak (ppsenak) ; 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 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, &g
Re: [Lsr] Technical questions for draft about unreachable prefixes announcement
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 On Behalf Of Ketan Talaulikar Sent: Monday, November 6, 2023 3:01 PM To: John Drake Cc: Peter Psenak (ppsenak) ; Aijun Wang ; 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 mailto: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 mailto: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 mailto: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
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 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 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
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
Re: [Lsr] Technical questions for draft about unreachable prefixes announcement
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 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
Re: [Lsr] Technical questions for draft about unreachable prefixes announcement
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. 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. 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. 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. 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] Technical questions for draft about unreachable prefixes announcement
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? 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? 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. 4) We can’t ignore the partitions scenarios or let’s it go. 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 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
