> On Aug 31, 2023, at 12:32, Robert Raszuk <[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] https://www.ietf.org/mailman/listinfo/lsr
