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

[Ketan Talaulikar <[e-mail]>]

Hi Acee,

I agree with your so-called "baseless comments" on the differences between
the two drafts but I still hold some hope for further convergence between
the two proposals.

Thanks,
Ketan


On Thu, Jul 28, 2022 at 11:33 PM Acee Lindem (acee) <[e-mail]> wrote:

> 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]>
> 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]> 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]> *On Behalf Of *Ketan Talaulikar
> *Sent:* Wednesday, July 27, 2022 1:36 AM
> *To:* [e-mail]
> *Cc:* lsr <[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]
> https://www.ietf.org/mailman/listinfo/lsr
>
>