Re: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02

Christian Hopps <chopps@chopps.org> Wed, 10 August 2022 01:14 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E354FC14F73E; Tue, 9 Aug 2022 18:14:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8RQRmIztU7l; Tue, 9 Aug 2022 18:14:02 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE16C14F738; Tue, 9 Aug 2022 18:14:01 -0700 (PDT)
Received: from ja.int.chopps.org.chopps.org (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 8121E7D07D; Wed, 10 Aug 2022 01:14:00 +0000 (UTC)
References: <m2tu6lttjk.fsf@ja.int.chopps.org> <756C812B-E31A-44DE-B171-3C459ED2EFC4@tsinghua.org.cn> <m2pmh8udkm.fsf@ja.int.chopps.org>
User-agent: mu4e 1.8.5; emacs 28.0.92
From: Christian Hopps <chopps@chopps.org>
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: Christian Hopps <chopps@chopps.org>, "Acee Lindem (acee)" <acee@cisco.com>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, lsr-chairs@ietf.org, lsr-ads@ietf.org, lsr@ietf.org
Date: Tue, 09 Aug 2022 20:56:12 -0400
In-reply-to: <m2pmh8udkm.fsf@ja.int.chopps.org>
Message-ID: <m2lerwuch4.fsf@ja.int.chopps.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/uBz8j7_rwJHQBoe6Ca5UjL7fIS4>
Subject: Re: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Aug 2022 01:14:06 -0000

Christian Hopps <chopps@chopps.org> writes:

> [[PGP Signed Part:Good signature from 2E1D830ED7B83025 Christian Hopps <chopps@gmail.com> (trust ultimate) created at 2022-08-09T20:50:17-0400 using RSA]]
>
> Aijun Wang <wangaijun@tsinghua.org.cn> writes:
>
>> Hi, Chris:
>> If so, let’s adopt them directly then, why seek the opinions from the WG?
>
> This is a valid point. I will consult with Acee and John, perhaps doing an
> adoption call was unneeded, and they should be considered adopted already as
> they are only clarification changes to work this group has already published.

Alternatively, you could also recognize (it's been stated by the chairs at this point as well) that these are clarification drafts for published RFCs, and as such your objections are being made within that scope.

So, by objecting within this scope what you are saying is "I would like to leave the published standards in a less clear state b/c I don't like them".

In any case your opinion has been noted.

Thanks,
Chris.


>
> Thanks,
> Chris.
>
>
>> I would like to illustrate my opinions again:
>> Application specific attributes just one small part of the application based
>> solution, there are other issues needed to be considered and solved. And I think
>> the alternative systematic solution will obsolete RFC8919 and RFC8920 together.
>> The bis draft are just repeating its precedent, and will be replaced also accordingly, unless it solves the issues that I mentioned.
>>
>> Aijun Wang
>> China Telecom
>>
>>> On Aug 9, 2022, at 21:50, Christian Hopps <chopps@chopps.org> wrote:
>>>
>>> 
>>> We were asked by the AD to process these clarifications using bis drafts, rather than errata. That is what this is. There should be no controversy here. Let's not create any, please.
>>>
>>> Thanks,
>>> Chris.
>>>
>>> Aijun Wang <wangaijun@tsinghua.org.cn> writes:
>>>
>>>> Hi, Acee, Peter:
>>>>
>>>> If there is no significant updates for these two RFCs, I recommend we delay the obsolete of them, also the adoption call for these two bis drafts.
>>>> What we should do is to find other more scalable, extensible and systematic approaches for the application specified advertisements.
>>>>
>>>> For example, for the multiple application scenarios, is it enough just define the application specified attributes?
>>>>
>>>> From my understandings, different applications may build different LSDBs, run
>>>> different SPF algorithm, update at different frequencies, forming different
>>>> forwarding tables etc. It is necessary to divide/group all the above items based
>>>> on application, not just the attributes.
>>>>
>>>>
>>>> Aijun Wang
>>>> China Telecom
>>>>
>>>>>> On Aug 9, 2022, at 18:31, Acee Lindem (acee) <acee@cisco.com> wrote:
>>>>>
>>>>> Hi Aijun,
>>>>>
>>>>> And the BIS changes are more clarifications than changes to the existing RFC 8919 and RFC 8920 RFCs.
>>>>>
>>>>> Thanks,
>>>>> Acee
>>>>>
>>>>> On 8/9/22, 5:57 AM, "Peter Psenak" <ppsenak@cisco.com> wrote:
>>>>>
>>>>>   Aijun,
>>>>>
>>>>>>   On 09/08/2022 05:35, Aijun Wang wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I am wondering why we are so hurry to obsolete RFC8919, given that only the
>>>>>> minor parts are  updated (mainly the zero length SABM/UABM, and other
>>>>>> interoperability issues).
>>>>>> There may be other methods to advertise the application specific attributes.
>>>>>>> From my POV, the rules, implementation of ASLA are still complex, the
>>>>>> deployment of them are challenging.
>>>>>>
>>>>>> Is there any real deployment for RFC8919 until now?
>>>>>
>>>>>   sure there are deployments of it. Flex-algo is built around RFC8919, so
>>>>>   any network where flex-algo is used with ISIS is using RFC8919.
>>>>>
>>>>>   Peter
>>>>>
>>>>>>
>>>>>> Best Regards
>>>>>>
>>>>>> Aijun Wang
>>>>>> China Telecom
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: lsr-bounces@ietf.org <lsr-bounces@ietf.org> On Behalf Of Christian
>>>>>> Hopps
>>>>>> Sent: Monday, August 8, 2022 6:17 PM
>>>>>> To: lsr@ietf.org
>>>>>> Cc: chopps@chopps.org; lsr-chairs@ietf.org; lsr-ads@ietf.org
>>>>>> Subject: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02
>>>>>>
>>>>>>
>>>>>> Hi Folks,
>>>>>>
>>>>>> This begins a 2 week WG Adoption Call for the following draft:
>>>>>>
>>>>>>  https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/
>>>>>>
>>>>>> Please indicate your support or objections by August 22nd, 2022.
>>>>>>
>>>>>> Authors, please respond to the list indicating whether you are aware of any
>>>>>> IPR that applies to these drafts.
>>>>>>
>>>>>> Thanks,
>>>>>> Chris.
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>
>>
>> [2. application/octet-stream; signature.asc]...
>
> [[End of PGP Signed Part]]

a