Hi Aijun, > On Aug 31, 2023, at 23:36, Aijun Wang <[email protected]> wrote: > > Hi，Acee: > > Please read > https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-7 > before making misguide assertions: > > “The advertisement of PUAM message should only last one configurable period > to allow the services that run on the failure prefixes are switchovered.”
I guess I haven’t kept up with all the elements of the draft under adoption that you continue to incorporate into your draft. This has been a continuing theme since initial discussed of the application signaling use case. While I have no interest in improving your draft, making the LSP/LSA short-lived conflicts with the other scenarios your draft purports to address. Acee > > Best Regards > > Aijun Wang > China Telecom > > 发件人: [email protected] <mailto:[email protected]> > [mailto:[email protected]] 代表 Acee Lindem > 发送时间: 2023年9月1日 0:50 > 收件人: Robert Raszuk <[email protected] <mailto:[email protected]>> > 抄送: Les Ginsberg (ginsberg) <[email protected] > <mailto:[email protected]>>; Huzhibo > <[email protected] > <mailto:[email protected]>>; Peter Psenak > <[email protected] <mailto:[email protected]>>; linchangwang > <[email protected] <mailto:[email protected]>>; lsr > <[email protected] <mailto:[email protected]>> > 主题: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" > - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 > > > > >> On Aug 31, 2023, at 12:32, Robert Raszuk <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Acee, >> >>> In any case, one will need to update the signaling routers and the routers >>> acting on the signal. >> >> I guess this is clear to all. >> >>> Additionally, your request for the adoption was that the draft have a >>> stronger statement about the mechanism being used for solely for signaling >>> for applications (e.g., BGP PIC). >> >> As to the applicability my comment was that either draft should state in >> strong normative language that this is applicable only to applications which >> data plane uses encapsulation to the next hop. >> >> Said this draft-wang introduces the additional signalling, sort of trying to >> assure that all nodes in an area understand the new messages - but I am not >> sure if even advertising PUAM capability means that it will be actually used >> for all destinations ? > > No - but while the draft under adoption (ppsenak-lsr…) is for an ephemeral > signal which the WG agreed was a valid use case, in the other draft, the LSAs > are long-lived and are also may be used for other purposed than signaling > (e.g., reread both sections 4 and 6 of draft-wang-lsr…). This draft starting > with a whole different use case but selectively added mechanisms from > ppsenak-lsr… > > I seem to recall you were a strong proponent of limiting the scope. > > > >> >>> By responding to this Email inline, some may believe you support the >>> assertion that we should start the adoption of both drafts. Please be >>> clarify this. >> >> Well the way I see this is that adoption call is a bit more formal >> opportunity for WG members to express their opinion on any document. But >> maybe LSR (for good reasons) have different internal rules to decide which >> document should be subject to WG adoption and does sort of pre-filtering. >> >> If adoption call proves document has negative comments or lacks cross vendor >> support it simply does not get adopted. >> >> Maybe I am just spoiled looking at how IDR WG process works :-) > > You replied to an Email inline suggesting adoption of both drafts. That is > what I think could have been misconstrued - especially by those who didn’t > follow the discussion until now who think you are agreeing with this > recommendation. > > > >> >>> As for your other comment that this could be accomplished with BGP or an >>> out-of-bound mechanism, that is true but that could be true of many >>> problem. However, the solution under adoption has running code and wide >>> vendor support. >> >> Right ... As I wrote to Peter - perhaps this is just a pragmatic approach >> and flooding is what link state uses so be it. >> >> As you know I did try in the past to propose BGP Aggregate withdraw but then >> feedback of the community was that PEs do not go down that often to justify >> the extension. > > Hmm… We seem to have broad support for the LSR application signaling use > case. > > Thanks, > Acee > > > >> >> Best, >> Robert >> > > > _______________________________________________ > Lsr mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
