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) <a...@cisco.com> 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 <lsr-boun...@ietf.org> on behalf of Ketan Talaulikar < > ketant.i...@gmail.com> > *Date: *Thursday, July 28, 2022 at 2:29 AM > *To: *Aijun Wang <wangai...@tsinghua.org.cn> > *Cc: *"Les Ginsberg (ginsberg)" <ginsberg=40cisco....@dmarc.ietf.org>, " > draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org" < > draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org>, lsr <lsr@ietf.org > > > *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 <wangai...@tsinghua.org.cn> > 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= > 40cisco....@dmarc.ietf.org> 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 <lsr-boun...@ietf.org> *On Behalf Of *Ketan Talaulikar > *Sent:* Wednesday, July 27, 2022 1:36 AM > *To:* draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org > *Cc:* lsr <lsr@ietf.org> > *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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
