Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement

["Acee Lindem (acee)" <[e-mail]>]

Speaking as WG Member:

Hi Ketan,

Thanks for pointing out the similarities. Even after the recent changes,  there are still some difference between the drafts which I’ll describe in the baseless comments which follow. For conciseness, I’ll refer to the drafts as PUA (Draft Wang) and UPA (Draft Psenak).


  1.  Backward Compatibility – Now that PUA has appropriated the metric mechanisms from UPA, it is also backward compatible. However, PUA still proposes extensions the IGPs to advertise the PUA capabilities and says the nodes may misbehave if they don’t agree on these capabilities. I guess removing these was omitted when the UPA metric mechanisms were appropriated.
  2.  Receive Router Behavior – For UPA, the unreachable prefix notification is solely for an event signal to be used by other routers in the IGP domain to trigger actions, e.g., BGP PIC excluding the unreachable prefix.  PUA is used for the switchover of services as well but is also used to modify persistent state. In section 4, the PUA advertisement will trigger the advertisement of the prefix by an ABR that does have a route to the unreachable prefix advertised by another ABR.
  3.  Advertisement Persistence – PUA is advertised like any other LSA and presumably advertised as long as the prefix is unreachable. Conversely, UPA is an ephemeral LSA that will be withdrawn after enough time is allowed for the event notification to propagate.

In my opinion, UPA is superior to PUA since it is addresses the original requirement with minimal overhead and changes to the IGP. Even after many revisions, PUA still contains a lot of additional unnecessary overhead and complexity. I think the WG should adopt UPA and not spend any more time on this discussion.

Thanks,
Acee

From: Lsr <[e-mail]> on behalf of Ketan Talaulikar <[e-mail]>
Date: Thursday, July 28, 2022 at 2:29 AM
To: Aijun Wang <[e-mail]>
Cc: "Les Ginsberg (ginsberg)" <ginsberg=[e-mail]>, "[e-mail]" <[e-mail]>, lsr <[e-mail]>
Subject: Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement

Hi Aijun,

Indeed, your draft has done a "pivot" in the latest version with the use of LSInfinity like the UPA proposal. I hope you will do yet another "pivot" to move away from the use of Prefix Originator.

IMHO that would also bring the PUA and UPA proposals much closer to each other.

Thanks,
Ketan


On Thu, Jul 28, 2022 at 6:52 AM Aijun Wang <[e-mail]<mailto:[e-mail]>> wrote:
Hi, Les:

I admire you and your comments as usual, but the baseless comments will decrease your credits within the WG. Would you like to review the update of the draft more carefully, then post your comments? Doing this can avoid misleading some of your followers.

To facilitate your review, I copied the related contents again:(https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10#section-5)



  If not all of nodes within one area support the PUAM capabilities,

   the PUAM message should be advertised with the associated prefix cost

   set to LSInfinity.  According to the description in [RFC2328<https://datatracker.ietf.org/doc/html/rfc2328>],

   [RFC5305<https://datatracker.ietf.org/doc/html/rfc5305>] and [RFC5308<https://datatracker.ietf.org/doc/html/rfc5308>], the prefix advertised with such metric value

   will not be considered during the normal SPF computation, then such

   additional information will avoid the misbehavior of the nodes when

   they don't recognize the PUAM message.



   If all of nodes within one area support the PUAM capabilites, the

   PUAM message can be safely advertised without the additional

   LSInfinity metric information.

Then, how can the “legacy nodes MUST interpret as meaning reachable.” ? I wish to hear your explanation.

Aijun Wang
China Telecom


On Jul 28, 2022, at 06:39, Les Ginsberg (ginsberg) <ginsberg=[e-mail]<mailto:[e-mail]>> wrote:
(Preamble: All of what I am going to say I have said many times before – on the list – off the list – in private conversations – in WG meetings…
I don’t say this to start a discussion with the WG authors – it seems clear that we don’t agree and have no path to agreement.
My purpose in saying this is to respond to the ongoing existence of this draft and offering my opinion as to what action the WG should take.)

The mechanism defined in this draft is broken. Not only is it not backwards compatible – the PUA advertisements will be misinterpreted to mean the exact opposite of what is intended i.e., the intent is to signal that a prefix is unreachable, but you do so by using an advertisement which legacy nodes MUST interpret as meaning reachable. This is simply broken and should not be done.

The authors deserve credit for bringing the attention of the WG to the problem space – but the solution offered is not deployable. Given the long period of time during which this draft has been published and the many times it has been presented/discussed in the WG I think it is now time to say thank you to the authors for their work, but the WG is not interested in adopting this draft.

   Les


From: Lsr <[e-mail]<mailto:[e-mail]>> On Behalf Of Ketan Talaulikar
Sent: Wednesday, July 27, 2022 1:36 AM
To: [e-mail]<mailto:[e-mail]>
Cc: lsr <[e-mail]<mailto:[e-mail]>>
Subject: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement

Hello Authors,

I am sharing some comments on the latest version of this document since we seem to have a packed agenda in LSR this time.

1) I notice that in the latest update of the draft, there is a big change to start using LSInfinity for indicating prefix unreachability (similar to draft-ppsenak-lsr-igp-ureach-prefix-announce). I see this as a sign of a degree of convergence between the two drafts.

2) However, I then question the motivation of the authors to continue with the bad design of overloading Prefix Originator and the added capability stuff on top. I don't wish to repeat why that design was an absolute NO-GO for me and I am glad to see the authors acknowledge the problem with misrouting by implementations not supporting this specification. So I don't see the point of still retaining all that.

Thanks,
Ketan

_______________________________________________
Lsr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lsr