+1 Sent from my iPhone
> On 27.07.2022, at 23:39, Les Ginsberg (ginsberg) > <[email protected]> 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 <[email protected]> On Behalf Of Ketan Talaulikar > Sent: Wednesday, July 27, 2022 1:36 AM > To: [email protected] > Cc: lsr <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
