Re: [Lsr] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Peter Psenak <[e-mail]>]

Aijun,

On 06/09/2023 11:02, Aijun Wang wrote:

> 
> My proposal is that we postpone the adoption of this draft, and discuss 
> offline the merger document on the coming IETF118 meeting.

I want to be very clear, there is nothing to be merged.

regards,
Peter

> Then, we can submit the merged document to the LSR WG for adoption call.
> 
>>
>> my 2c,
>> Peter
>>
>>
>>
>>
>>
>> On 06/09/2023 07:56, Aijun Wang wrote:
>>> Hi, Acee:
>>> AGAIN, before making some assertions, please check the following fact:
>>> Have you noticed the 00 version of 
>>> https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/ <https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/> was submitted on July 5, 2021?
>>> But the description about the short lived notification in 
>>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7 <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7> was on March 26, 2021.
>>> Then, which draft was the first?
>>> For the adoption call or merge efforts, I think the WG should 
>>> consider the following facts:
>>> 1)Which draft is the first to provide the use cases?
>>> 2)Which draft is the first to propose explicit signaling for 
>>> unreachable information?
>>> 3)Which draft is the first to propose short lived notification?
>>> 4)Which explicit signaling mechanism is simpler?
>>> 5)Which draft provides more mechanisms to cover more scenarios?
>>> The base document should be selected based on the answers of the 
>>> above questions.
>>> Select the base document doesn’t mean that it can’t be changed before 
>>> the adoption(I haven’t said “Without Change” is the merge condition).
>>> Actually, we welcome more authors to join us to finalize the document 
>>> and solution.
>>> As one of the most important WG within IETF, I think LSR WG should 
>>> respect the original contributions to the WG.
>>> It is too hurry to consider or adopt only the draft that you prefer, 
>>> especially the follower draft.
>>> Best Regards
>>> Aijun Wang
>>> China Telecom
>>> *发件人:*[e-mail] [mailto:[e-mail]] *代表 
>>> *Acee Lindem
>>> *发送时间:*2023年9月6日0:56
>>> *收件人:*Aijun Wang <[e-mail]>
>>> *抄送:*Robert Raszuk <[e-mail]>; Les Ginsberg (ginsberg) 
>>> <ginsberg=[e-mail]>; Huzhibo 
>>> <huzhibo=[e-mail]>; Peter Psenak 
>>> <[e-mail]>; linchangwang <[e-mail]>; lsr 
>>> <[e-mail]>
>>> *主题:*Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix 
>>> Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04
>>> Hi Aijun,
>>> When the WG discussion first indicated that this was a use case that 
>>> needed to be addressed, I don’t dispute that you immediately added it 
>>> to your draft.
>>> I have no doubt you would have purported support of any use case 
>>> under discussion.
>>> However, the first draft to address this use case with a short-lived 
>>> notification was 
>>> https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/ <https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/>
>>> Based on WG feedback and collaboration of multiple vendors, this 
>>> draft evolved to draft-ppsenak-lsr-igp-ureach-prefix-announce.
>>> While you’ve incorporated elements of the draft under discussion, 
>>> your draft still includes pieces (sometimes conflicting) from 
>>> previous use cases.
>>> There was an effort to merge the drafts but you declined unless your 
>>> draft was used (without change) as the base. I’m not sure your 
>>> motivation.
>>> Thanks,
>>> Acee
>>>    On Sep 1, 2023, at 20:25, Aijun Wang <[e-mail]
>>>    <mailto:[e-mail]>> wrote:
>>>    Hi, Acee:
>>>    Act as LSR chair, I think you should be more responsible to make any
>>>    unfounded assertions:
>>>    We have described the previous statements in
>>>    https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7 <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7>, March 26, 2021, one year before the 00 version of draft-ppsenak(March 25,2022)
>>>    Then, which draft copy or incorporate which draft?
>>>    Aijun Wang
>>>    China Telecom
>>>        On Sep 1, 2023, at 20:05, Acee Lindem <[e-mail]
>>>        <mailto:[e-mail]>> wrote:
>>>        Hi Aijun,
>>>            On Aug 31, 2023, at 23:36, Aijun Wang
>>>            <[e-mail]
>>>            <mailto:[e-mail]>> wrote:
>>>            Hi，Acee:
>>>            Please
>>>            readhttps://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-7 <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
>>>            *发件人:*[e-mail]
>>>            <mailto:[e-mail]>[mailto:[e-mail]
>>>            <mailto:[e-mail]>]*代表*Acee Lindem
>>>            *发送时间:*2023年9月1日0:50
>>>            *收件人:*Robert Raszuk <[e-mail]
>>>            <mailto:[e-mail]>>
>>>            *抄送:*Les Ginsberg (ginsberg)
>>>            <ginsberg=[e-mail]
>>>            <mailto:ginsberg=[e-mail]>>; Huzhibo
>>>            <huzhibo=[e-mail]
>>>            <mailto:huzhibo=[e-mail]>>; Peter Psenak
>>>            <[e-mail] <mailto:[e-mail]>>; linchangwang
>>>            <[e-mail]
>>>            <mailto:[e-mail]>>; lsr <[e-mail]
>>>            <mailto:[e-mail]>>
>>>            *主题:*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
>>>                <[e-mail] <mailto:[e-mail]>> 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
>>>            [e-mail] <mailto:[e-mail]>
>>>            https://www.ietf.org/mailman/listinfo/lsr
>>>            <https://www.ietf.org/mailman/listinfo/lsr>
>>>        _______________________________________________
>>>        Lsr mailing list
>>>        [e-mail] <mailto:[e-mail]>
>>>        https://www.ietf.org/mailman/listinfo/lsr
>>>        <https://www.ietf.org/mailman/listinfo/lsr>
>>>    _______________________________________________
>>>    Lsr mailing list
>>>    [e-mail] <mailto:[e-mail]>
>>>    https://www.ietf.org/mailman/listinfo/lsr
>>>    <https://www.ietf.org/mailman/listinfo/lsr>
>>
>> _______________________________________________
>> Lsr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lsr