Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

[Ketan Talaulikar <[e-mail]>]

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 <[e-mail]> 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=
> [e-mail]> wrote:
>
> 
>
> Ketan –
>
>
>
> I am very happy to be wrong in this case. 😊
>
> We are in full agreement.
>
>
>
>     Les
>
>
>
>
>
> *From:* Lsr <[e-mail]> *On Behalf Of * Ketan Talaulikar
> *Sent:* Monday, November 6, 2023 11:52 PM
> *To:* Les Ginsberg (ginsberg) <[e-mail]>
> *Cc:* John Drake <je_drake=[e-mail]>; Peter Psenak
> (ppsenak) <[e-mail]>; Aijun Wang <[e-mail]>;
> [e-mail]
> *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) <
> [e-mail]> 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 <[e-mail]> *On Behalf Of *Ketan Talaulikar
> *Sent:* Monday, November 6, 2023 3:01 PM
> *To:* John Drake <je_drake=[e-mail]>
> *Cc:* Peter Psenak (ppsenak) <[e-mail]>; Aijun Wang <
> [e-mail]>; [e-mail]
> *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=
> [e-mail]> 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 <
> [e-mail]> 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
>