Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
John E Drake <jdrake@juniper.net> Mon, 19 October 2020 14:09 UTC
Return-Path: <jdrake@juniper.net>
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 A37A03A0A7E; Mon, 19 Oct 2020 07:09:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=VT6/mnAK; dkim=pass (1024-bit key) header.d=juniper.net header.b=XFvCqgP9
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_pTRs3DiKxE; Mon, 19 Oct 2020 07:09:10 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7B753A0A8F; Mon, 19 Oct 2020 07:08:56 -0700 (PDT)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 09JE8ZfT013379; Mon, 19 Oct 2020 07:08:52 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=dAR6D8VbKRfy42OUVkx1H91wib5wFKlp/pak1p23o0E=; b=VT6/mnAKNcM08iCKKUnhgJVcawId1g+FbtTZqMlIGIS6AC3QLaBeefyjL1y6Tw3t5+RZ VR8AWFwXJz3nyp5XGzdT55It5j/HV6Qq91UU+F9xS2ehgQcX8qWtqN0BMF+0joxznyFP CCiRVz/wa3YbVmFWXZ3KISg/ytM/WMdF3VIAglINdXquQ8U15iyndvzQDpgOxQ+kv/nC H7Y51jLfgevKvLA6a2eTC4LdIGzWmK/GamCcDCKMOSRn0dBFVikKqN+QqPytqL2Qr80D ZpYXBRGTTr3SBeY4WpXZjZhMCZ9RNdTsmdLMxobvjxG/3pwJnjnZ3MXq5qh1SE5lJVmN 3A==
Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2175.outbound.protection.outlook.com [104.47.59.175]) by mx0a-00273201.pphosted.com with ESMTP id 347ympaf95-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Oct 2020 07:08:52 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hUwJz2zwSPi56suqUGPcDpAtyJAPocDRIlwzRVMd2vv1X9sCUkeSER1ksP0IihRErkVnHYrcFTKWyXaXPVHC6QF80UGuOlOGLx+JKw/9riZD9kauYwaQMVXlrpZ9D5whGPjgOo3d/3Hfnl1FkOOVHg0+gM0yn5OA6Ce2vJiV1qfIOp3lvVWN4xJDSkLG0GjInHiY/BqjLtg9i76Ikwtv1qIoZEySW+tLkD60CxyaO712GDBaw651pOabuMS2gTxzL6iq89b5IOlwPhzvdK6sgIx3T/kMA5greOVMM5dtsDRW117LTOsAjQnRsgxWXYk9wFqeFfmHnPogJhR5Y5QjfQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dAR6D8VbKRfy42OUVkx1H91wib5wFKlp/pak1p23o0E=; b=LliZHrPdqNq9sAeebAdrVzyw8jPSXuntYcDWf+w5QPTtVAeUcKtmJx+ql/Qab053bVgw2XzQmCsRwho2B+d8EbagrfaAp8iJuHyxCFLTQ8fQq8Kn9/0ZHjOpxOnrW+TXnMeNzAOkV2f4KfiP3FUo4dyjtBoDf7Lr4SFTkpt4XhA7Ytw3A1d5Oa+tTvcVst2XkVnQceXf4t54vlEMmKwsQQnOhc1NPxNYmdcTcG+mFmCWFr48mMOZI2VHxbm3Rk6sh1MVOv3EG/5Agt3INQYG02eqRTrA4RqzPGbVjRvpimKiGFNrNK2WLJaXJcgQaRFpFCmySA3cgKan5Dl1ub/5xg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dAR6D8VbKRfy42OUVkx1H91wib5wFKlp/pak1p23o0E=; b=XFvCqgP9MBi74pClZmhL07BQSSRcCq2fMUbwWY8y1ofmKZITytSb8aPf4g6v/q1dB1nrCZm6hKxp38zS+wotjjy+2LKGqZ3mYLKFM0c+uRPlfWXoFJSloj+FBpZ7TSeZPIKUPHNaon6vZa0Jg5mCB1ilEZ9fiGXpe+fT+ZPfCAI=
Received: from DM5PR05MB3388.namprd05.prod.outlook.com (2603:10b6:4:40::18) by DM6PR05MB4364.namprd05.prod.outlook.com (2603:10b6:5:a2::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.15; Mon, 19 Oct 2020 14:08:48 +0000
Received: from DM5PR05MB3388.namprd05.prod.outlook.com ([fe80::49db:8508:5310:7865]) by DM5PR05MB3388.namprd05.prod.outlook.com ([fe80::49db:8508:5310:7865%7]) with mapi id 15.20.3499.015; Mon, 19 Oct 2020 14:08:48 +0000
From: John E Drake <jdrake@juniper.net>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Aijun Wang <wangaijun@tsinghua.org.cn>, 'Christian Hopps' <chopps@chopps.org>
CC: "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, 'Jeff Tantsura' <jefftant.ietf@gmail.com>, "draft-ietf-lsr-ospf-prefix-originator@ietf.org" <draft-ietf-lsr-ospf-prefix-originator@ietf.org>, "lsr-ads@ietf.org" <lsr-ads@ietf.org>
Thread-Topic: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
Thread-Index: AQHWo8tCJIqrzId5sUmXrpGJFDH2DqmeMcAAgABE8gCAAA5ggIAAB1UAgABubBA=
Date: Mon, 19 Oct 2020 14:08:47 +0000
Message-ID: <DM5PR05MB3388FA19AE49D69B10244FF4C71E0@DM5PR05MB3388.namprd05.prod.outlook.com>
References: <AAkAHAAhDWbG7PkMOi2SNaqM.3.1602859073007.Hmail.wangaijun@tsinghua.org.cn> <303E621F-47AA-4309-AC85-32A597604C7C@chopps.org> <00b401d6a5bc$ac44e800$04ceb800$@tsinghua.org.cn> <BY5PR11MB43376B4704FF76C8691EB1D4C11E0@BY5PR11MB4337.namprd11.prod.outlook.com> <00ea01d6a5e6$54f371f0$feda55d0$@tsinghua.org.cn> <BY5PR11MB43378864ED45AEDE428585E2C11E0@BY5PR11MB4337.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB43378864ED45AEDE428585E2C11E0@BY5PR11MB4337.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.5.0.60
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-10-19T14:08:43Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=07176a2d-0e7d-474b-b46c-bcfd857e7735; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 29eca1f5-4266-4265-6658-08d874387fb7
x-ms-traffictypediagnostic: DM6PR05MB4364:
x-microsoft-antispam-prvs: <DM6PR05MB4364B4F28AA099A803508718C71E0@DM6PR05MB4364.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: HrLiLft4zxQLJ64iWGs+JuEtLisfw8m0Z7r70ALCjSd/dCXycP1amEz3540/avRrDsl3FMIzB0++RIKQa90Tr9xIqqeGi5AS4QbIXtKm+QTuG8RRFHZgqusxIBnz5eXMgNqWRDftyi1DgFjSGpX5D9qvJPa9YbZYKhlegy02bmgB8F42zIIC/m5kmrnWTveCrXkrH+falJ10M7oYuKllysP75KVQZvlT51yghqUvnj7XJcZuduPpSZCQ7xlG3AHH42yWqOhhCJ1DNuane/Fq4fqSrTrP0RjlSLHzrs5kR83MrBcy/EtSMS218O/J05yQzu7YoKAIRgKMTW0YTNx8vF3k4cAJ2lPRqvwNqIAn/o2kDqsopnkx0BYMUZET4DuTya23uYUNfkw5GJinD1h88w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR05MB3388.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(366004)(346002)(39860400002)(376002)(2906002)(83380400001)(8936002)(4326008)(186003)(66574015)(76116006)(26005)(316002)(7696005)(66476007)(66556008)(64756008)(66446008)(52536014)(66946007)(478600001)(55016002)(9686003)(966005)(71200400001)(53546011)(6506007)(54906003)(86362001)(8676002)(33656002)(5660300002)(110136005)(30864003)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: xLzNF5z/8xRlnhud2xBqUBn3MTgzmaSr6HpV+d8L1yKNeniOdsziu1h+mMWIQMA7NBLISPJMdXMaqdwI1HlAibZ3goEFdoB3T4+iFtgJiT+7I2coTOH8ckF9OespePVAgFdhqdsjXyxxtWfUcEL1ZXG/9PaNN2hEFN4boCXKo3yXS3phb5VXx6ExxAnpwMRpULD7pWWHkY3kjtwc2szIwgcCst8c9YOwZICfT8reyUO6cLr9FciU1iScBXa4xSMGLZuV2xZ6KFjdPgu3TEW/NKjt/29JrpDFNstbK/b/v1grFkBztHIvwKonAB1PHkCnTGnHg2wAkE2pPEtqsJrkQ+fx6Skbp7pYb9RjiqSVVT72Al1eMQzL6NX+OJHKD73WB830ot9mCxpsdcswMAiNQlEdFjSwR+kd4SE/Li1tWYiI+tRl707SOtyuG8Y7ywVV8+d0/8Kc/eIrwRWRJOQORPD4r3vEhphQD/JyLNJU6KXIkA9y6KPvQq5SJNf49giHYX626gL3RI+B+cGeOQtNcIccJ3Rba1VTsg5uyKf6ushW/uZ7LUrA8ow66gJm6En12sxbzDg147eXky9PEkVzZl3RSd9D3UscUjBNOL503E3rroBQHa6TG0SXkMtMFfk04wLjxwCf2Mxb+ucTLNwzgQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM5PR05MB3388.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 29eca1f5-4266-4265-6658-08d874387fb7
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2020 14:08:48.0192 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QEsyIdK0aK1FSbCE+59ZcKoWJxRixdPtbZrHflZHxtCJJsTOXy6LKMJequ+cHWOo8B6C6NUyBzunce05LmaLqQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4364
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-19_06:2020-10-16, 2020-10-19 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 suspectscore=0 mlxlogscore=999 phishscore=0 bulkscore=0 clxscore=1015 lowpriorityscore=0 adultscore=0 spamscore=0 impostorscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010190097
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/av5cdELGwHzHi7e97QYmJnHoXEA>
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 19 Oct 2020 14:09:14 -0000
I agree w/ Les, who I think has been extremely reasonable throughout this discussion. Yours Irrespectively, John Juniper Business Use Only > -----Original Message----- > From: Les Ginsberg (ginsberg) <ginsberg@cisco.com> > Sent: Monday, October 19, 2020 3:32 AM > To: Aijun Wang <wangaijun@tsinghua.org.cn>; 'Christian Hopps' > <chopps@chopps.org> > Cc: John E Drake <jdrake@juniper.net>; lsr-chairs@ietf.org; lsr@ietf.org; 'Jeff > Tantsura' <jefftant.ietf@gmail.com>; draft-ietf-lsr-ospf-prefix- > originator@ietf.org; lsr-ads@ietf.org > Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 > > [External Email. Be cautious of content] > > > Aijun - > > I am not going to continue these side discussions with you. > > The primary purpose of the protocol extensions are as stated in the draft > Introduction. This is analogous to the use cases for the equivalent extensions for > IS-IS already approved in RFC 7794. We need the equivalent in OSPF. > > You can show that you are listening to the concerns of WG members by > removing the Appendices - in which case you have (I believe) broad support for > moving the draft forward. > You can then write a separate draft to discuss other use cases and allow the WG > to discuss those other use cases w/o preventing the extensions from being > approved and deployed for the use cases which have already been > demonstrated as useful by IS-IS. > > If you remove the Appendices I can support the draft. > If you do not remove the Appendices I cannot support the draft. > > Please discuss this with your co-authors and come to consensus on your next > step. > > Les > > > > -----Original Message----- > > From: Aijun Wang <wangaijun@tsinghua.org.cn> > > Sent: Monday, October 19, 2020 12:06 AM > > To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; 'Christian Hopps' > > <chopps@chopps.org> > > Cc: 'John E Drake' <jdrake@juniper.net>; lsr-chairs@ietf.org; > > lsr@ietf.org; 'Jeff Tantsura' <jefftant.ietf@gmail.com>; > > draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org > > Subject: RE: [Lsr] WG Last Call > > draft-ietf-lsr-ospf-prefix-originator-06 > > > > Hi, Les: > > > > As I stated clearly before, the appendix described in the draft is not > > the new use case. It is the start point of this draft. > > Have you noticed that the introduction part is not the final usage of > > such protocol extension information? > > Certainly, we will not expand all the possible use cases in very > > detail, but putting some of them(some interesting, prominent use > > cases) in the appendix will not hamper the protocol extension itself. > > > > If the statements/descriptions in the appendix are not correct, we can > > fix it, or remove it finally. If not, why not let it be for reference > > to the user of such protocol extension? > > For the body part of this draft, we are also welcome comments. > > > > More replies inline below[WAJ] > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > -----Original Message----- > > From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of > > Les Ginsberg (ginsberg) > > Sent: Monday, October 19, 2020 2:15 PM > > To: Aijun Wang <wangaijun@tsinghua.org.cn>; 'Christian Hopps' > > <chopps@chopps.org> > > Cc: 'John E Drake' <jdrake@juniper.net>; lsr-chairs@ietf.org; 'Les > > Ginsberg (ginsberg)' <ginsberg=40cisco.com@dmarc.ietf.org>; > > lsr@ietf.org; 'Jeff Tantsura' <jefftant.ietf@gmail.com>; > > draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org > > Subject: Re: [Lsr] WG Last Call > > draft-ietf-lsr-ospf-prefix-originator-06 > > > > Aijun - > > > > The "use case" for the protocol extensions is clearly stated in the > > Introduction: > > > > "The primary use case for the extensions proposed in this document is > > to be able to identify the originator of the prefix in the network. > > In cases where multiple prefixes are advertised by a given router, it > > is also useful to be able to associate all these prefixes with a > > single router even when prefixes are advertised outside of the area > > in which they originated. It also helps to determine when the same > > prefix is being originated by multiple routers across areas." > > > > This is equivalent to language in RFC 7794 which defines the analogous > > extensions for IS-IS. > > > > Everything you have in the Appendix is not related to the primary use > > case - and is fact a use case which many of us have objected to. > > [WAJ] Very glad to know the false statements in the appendix. > > > > You are entitled to write another draft advocating for your new use > > case if you wish, but requiring that the protocol extensions in > > support of the primary use case not go forward without your new use > > case is - as Chris has stated very clearly - holding approval of the > > protocol extensions hostage to your new use case. > > [WAJ] It is not new use case. As I sated before, I am open to this > > part, but should on the conditions that the statements in this part are > incorrect. > > > > I am asking you (yet again) not to do this. > > > > I cannot support the document moving forward with the content in the > > Appendices included. > > [WAJ] Would like to hear more technical analysis. > > > > Les > > > > > > > -----Original Message----- > > > From: Lsr <lsr-bounces@ietf.org> On Behalf Of Aijun Wang > > > Sent: Sunday, October 18, 2020 7:08 PM > > > To: 'Christian Hopps' <chopps@chopps.org> > > > Cc: 'John E Drake' <jdrake@juniper.net>; lsr-chairs@ietf.org; 'Les > > > Ginsberg (ginsberg)' <ginsberg=40cisco.com@dmarc.ietf.org>; > > > lsr@ietf.org; 'Jeff Tantsura' <jefftant.ietf@gmail.com>; > > > draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org > > > Subject: Re: [Lsr] WG Last Call > > > draft-ietf-lsr-ospf-prefix-originator-06 > > > > > > Hi, Chris: > > > > > > I think we have "put the cart before the horse". For protocol > > > extension draft, the origin is the use case. > > > And I think we will not expand OSPF protocol, just because it lack > > > something as compared with ISIS, right? > > > > > > As I stated before, the use case in current appendix is the main > > > motivation of this draft, you can see this in main body of the > > > earlier version of this draft(from version 0 to version 5). > > > The reason that we move this part to the appendix, as that you said, > > > is to let person focus on the protocol extension itself. > > > > > > Moving this part to appendix is acceptable, but removing it from the > > > draft will erase the origin of this document. > > > Is it reasonable that one document discusses the "origin"(of the > > > prefix), can't keep its origin? > > > > > > More replies inline below[WAJ]. > > > > > > Best Regards > > > > > > Aijun Wang > > > China Telecom > > > > > > > > > -----Original Message----- > > > From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf > > > Of Christian Hopps > > > Sent: Friday, October 16, 2020 10:47 PM > > > To: 王爱俊 <wangaijun@tsinghua.org.cn> > > > Cc: John E Drake <jdrake@juniper.net>; Christian Hopps > > > <chopps@chopps.org>; lsr-chairs@ietf.org; Les Ginsberg (ginsberg) > > > <ginsberg=40cisco.com@dmarc.ietf.org>; lsr@ietf.org; Jeff Tantsura > > > <jefftant.ietf@gmail.com>; > > > draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr- ads@ietf.org > > > Subject: Re: [Lsr] WG Last Call > > > draft-ietf-lsr-ospf-prefix-originator-06 > > > > > > Isn't this just adding an analogous extension that already exists in RFC7794? > > > [WAJ] No. RFC7794 is just one example that to illustrate, as the > > > companion IGP protocol, OSPF can also accomplish this. And, > > > actually, there are differences consideration in this draft for the protocol > extension. > > > > > > I don't think we need to do a lot of convincing at this point. I > > > agree with Les, if you want to talk about use cases (especially ones > > > that are controversial!) then the correct place for that is in a new > > > informative > > draft. > > > [WAJ] we have discussed the use case before and state the discussion > > > results at the appendix part. We will not emphasis and expand the > > > use case more. If one does not agree the statement of this appendix, > > > we can discuss online or offline. We just need to make the statement > > > in > > appendix is correct. > > > > > > Otherwise, especially if the cases are controversial, this can be > > > seen as doing an "end-run" to avoid the debate b/c people want the > > > extension, but maybe don't agree with your use case. > > > [WAJ] One should point out which statement in the appendix is > > > controversial, we can correct it. This use case is the origin of > > > this draft, not the results. > > > > > > Legislators do this sometimes adding things they want personally to > > > popular bills, that other people may not want, but since people want > > > the main bill they vote for it anyway, in the US it's called "adding > > > pork" or "pork barrel politics". :) [WAJ] The appendix is not added > > > later, but exist at the first beginning. This is the origin of the > > > bills. > > > > > > Thanks, > > > Chris. > > > > > > > On Oct 16, 2020, at 10:37 AM, 王爱俊 <wangaijun@tsinghua.org.cn> > > > wrote: > > > > > > > > > > > > Hi, Chris: > > > > Originally, the appendix part is within the document, which is the > > > > start > > > point/main motivation to extend the prefix origin. > > > > There may exists other usages of this information. Pack these > > > > examples > > > into some short sentences or introduction is viable, but expand some > > > of them is also helpful. > > > > As I known, when we want to do protocol extension, we should > > > > always > > > convince other the reason/motivation/prospects to do so. On the > > > other hand, the use case described in the current appendix is very > > > prominent for operator to accomplish the TE task in multi-area environment. > > > > > > > > Aijun Wang > > > > > > > > 在2020-10-16,Christian Hopps <chopps@chopps.org>写道: > > > > -----原始邮件----- > > > > 发件人: Christian Hopps <chopps@chopps.org> > > > > 发件时间: 2020年10月16日 星期五 > > > > 写道: ["Les Ginsberg (ginsberg)" > > > > <ginsberg=40cisco.com@dmarc.ietf.org>] > > > > 主题: Re: [Lsr] WG Last Call > > > > draft-ietf-lsr-ospf-prefix-originator-06 > > > > > > > > > On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg) > > > <ginsberg=40cisco.com@dmarc.ietf.org> wrote: > > > > > > > > > > Aijun - > > > > > > > > > > The point I am making is very focused. > > > > > > > > > > This draft is defining a protocol extension. As such it is > > > > > necessary that this > > > be Standards track as adhering to the normative statements in the > > > draft are necessary for interoperability. > > > > > > > > > > What is discussed in the Appendix is a use case. It is not > > > > > normative and > > > there are strong opinions on both sides as to whether this is an > > > appropriate use case or not. > > > > > In the context of this draft, I have no interest in trying to > > > > > resolve our > > > difference of opinion on this use case. I simply want the protocol > > > extension to move forward so that we have another tool available. > > > > > > > > > > If you want to write a draft on the use case discussed in the > > > > > Appendix > > > please feel free to do so. That draft may very well not be normative > > > - Informational or BCP may be more appropriate - because it will be > > > discussing a deployment scenario and a proposal to use defined > > > protocol extensions as one way to solve problems in that deployment > > > scenario. Such a draft might also be more appropriate in another WG > > > (e.g., TEAS). The merits of using prefix advertisements to build a > > > topology > > could then be discussed on its own. > > > > > > > > > > Please do not try to avoid having a full discussion of the > > > > > merits of using > > > prefix advertisements to derive topology by adding it to a draft > > > that is (and should be) focused on simple protocol extensions. > > > > > > > > [As WG member] > > > > > > > > I find this very compelling and so support the removal of the > > > > referred to > > > non-normative appendices. > > > > > > > > Thanks, > > > > Chris. > > > > > > > > > > > > > > Thanx. > > > > > > > > > > Les > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: Aijun Wang <wangaijun@tsinghua.org.cn> > > > > >> Sent: Thursday, October 15, 2020 6:51 PM > > > > >> To: 'Jeff Tantsura' <jefftant.ietf@gmail.com>; 'John E Drake' > > > > >> <jdrake@juniper.net> > > > > >> Cc: 'Christian Hopps' <chopps@chopps.org>; lsr-chairs@ietf.org; > > > > >> Les Ginsberg > > > > >> (ginsberg) <ginsberg@cisco.com>; lsr@ietf.org; > > > > >> lsr-ads@ietf.org; > > > > >> draft-ietf- lsr-ospf-prefix-originator@ietf.org > > > > >> Subject: RE: [Lsr] WG Last Call > > > > >> draft-ietf-lsr-ospf-prefix-originator-06 > > > > >> > > > > >> Hi, Les, John and Jeff: > > > > >> > > > > >> Let's reply you all together. > > > > >> In my POV, The standard document should not define solely the > > > > >> protocol extension, but their usages in the network deployment. > > > > >> As I known, almost all the IETF documents following this style. > > > > >> And, before adopting one work, we have often intense discussion > > > > >> for what's their usages. > > > > >> Such discussion in the mail list and statements in the document > > > > >> can certainly assist the reader/user of the document get the > > > > >> essence of the standard, and follow them unambiguously. > > > > >> > > > > >> Regarding the contents of appendices, as stated in the section, > > > > >> "The Appendix A heuristic to rebuild the topology can normally > > > > >> be used if all links are numbered." I think this can apply > > > > >> almost most of the operator's network, and facilitate the > > > > >> inter-area TE path calculation for central controller, or even > > > > >> for the head-end router that located in one area that different from the > tail- end router. > > > > >> > > > > >> Keeping the contents of appendices does not have the negative > > > > >> impact of the protocol extension, it is just one reference for > > > > >> the usage of this extension. > > > > >> One can select not refer to it, if their networks are deployed > > > > >> with large amount of unnumbered links. But for others, the > > > > >> heuristic > > applies. > > > > >> > > > > >> Best Regards > > > > >> > > > > >> Aijun Wang > > > > >> China Telecom > > > > >> > > > > >> > > > > >> > > > > >> -----Original Message----- > > > > >> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On > > > > >> Behalf Of Jeff Tantsura > > > > >> Sent: Friday, October 16, 2020 5:28 AM > > > > >> To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org> > > > > >> Cc: Christian Hopps <chopps@chopps.org>; lsr-chairs@ietf.org; > > > > >> Les Ginsberg > > > > >> (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org>; lsr@ietf.org; > > > > >> lsr- ads@ietf.org; > > > > >> draft-ietf-lsr-ospf-prefix-originator@ietf.org > > > > >> Subject: Re: [Lsr] WG Last Call > > > > >> draft-ietf-lsr-ospf-prefix-originator-06 > > > > >> > > > > >> +1 > > > > >> > > > > >> Regards, > > > > >> Jeff > > > > >> > > > > >>> On Oct 15, 2020, at 11:33, John E Drake > > > > >> <jdrake=40juniper.net@dmarc.ietf.org> wrote: > > > > >>> > > > > >>> Hi, > > > > >>> > > > > >>> I agree with Les. This is a simple protocol extension for a > > > > >>> specific purpose > > > > >> and there is no reason to include speculation about its use for > > > > >> other purposes, particularly when it is inherently not suited for them. > > > > >>> > > > > >>> Yours Irrespectively, > > > > >>> > > > > >>> John > > > > >>> > > > > >>> > > > > >>> Juniper Business Use Only > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Les Ginsberg > > > > >>>> (ginsberg) > > > > >>>> Sent: Thursday, October 15, 2020 12:33 PM > > > > >>>> To: Christian Hopps <chopps@chopps.org>; lsr@ietf.org > > > > >>>> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org; > > > > >>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org > > > > >>>> Subject: Re: [Lsr] WG Last Call > > > > >>>> draft-ietf-lsr-ospf-prefix-originator-06 > > > > >>>> > > > > >>>> [External Email. Be cautious of content] > > > > >>>> > > > > >>>> > > > > >>>> I support moving this document forward. > > > > >>>> Similar functionality in IS-IS has proved useful. > > > > >>>> > > > > >>>> I would however like to repeat comments I made earlier in the > > > > >>>> review of this document. > > > > >>>> The content of the Appendices should be removed. > > > > >>>> The Appendices define and discuss deriving topology > > > > >>>> information from prefix advertisements - which is flawed and > > > > >>>> should not be > > done. > > > > >>>> Perhaps more relevant, the purpose of the document is to > > > > >>>> define protocol extensions supporting advertisement of the > > > > >>>> originators of a prefix advertisement. There is no need to > > > > >>>> discuss how this mechanism might be used to build topology > information. > > > > >>>> This document should confine itself to defining the protocol > > > > >>>> extensions - similar the RFC 7794. > > > > >>>> > > > > >>>> If the authors do not agree to do this, I would encourage > > > > >>>> this point to be discussed during IESG review. > > > > >>>> > > > > >>>> Les > > > > >>>> > > > > >>>>> -----Original Message----- > > > > >>>>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Christian > > > > >>>>> Hopps > > > > >>>>> Sent: Wednesday, October 14, 2020 11:15 PM > > > > >>>>> To: lsr@ietf.org > > > > >>>>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; > > > > >>>>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps > > > > >>>>> <chopps@chopps.org> > > > > >>>>> Subject: [Lsr] WG Last Call > > > > >>>>> draft-ietf-lsr-ospf-prefix-originator-06 > > > > >>>>> > > > > >>>>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for: > > > > >>>>> > > > > >>>>> > > > > >>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc > > > > >>>>> /d > > > > >>>>> ra > > > > >>>>> ft-i > > > > >>>>> et > > > > >>>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO- > > > > >> gk!TaSzQThghtCFOuYPS2VjLq > > > > >>>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ > > > > >>>>> > > > > >>>>> The following IPR has been filed > > > > >>>>> > > > https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;! > > > > >>>>> !NEt6yMaO- > > > > >>>> > > > gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz > > > > >>>>> 5KtUHQ$ > > > > >>>>> > > > > >>>>> Authors, > > > > >>>>> > > > > >>>>> Please indicate to the list, your knowledge of any other IPR > > > > >>>>> related to this work. > > > > >>>>> > > > > >>>>> Thanks, > > > > >>>>> Chris. > > > > >>>> > > > > >>>> _______________________________________________ > > > > >>>> Lsr mailing list > > > > >>>> Lsr@ietf.org > > > > >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/list > > > > >>>> in > > > > >>>> fo > > > > >>>> /lsr > > > > >>>> __;!!NEt > > > > >>>> 6yMaO- > > > > >>>> > > > > >> > > > > > gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm > > > > >> w8 > > > > >>>> Lc$ > > > > >>> > > > > >>> _______________________________________________ > > > > >>> Lsr mailing list > > > > >>> Lsr@ietf.org > > > > >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listi > > > > >>> nfo/lsr__;!!NEt6yMaO- > gk!UgEi3bxNDS6ZLnXNliOvkQtMeXCTCwwSe0ToOV > > > > >>> 9UMD54R3w20E_CXC5-bVuZr-c$ > > > > >> > > > > >> _______________________________________________ > > > > >> Lsr mailing list > > > > >> Lsr@ietf.org > > > > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listin > > > > >> fo/lsr__;!!NEt6yMaO- > gk!UgEi3bxNDS6ZLnXNliOvkQtMeXCTCwwSe0ToOV9U > > > > >> MD54R3w20E_CXC5-bVuZr-c$ > > > > > > > > > > _______________________________________________ > > > > > Lsr mailing list > > > > > Lsr@ietf.org > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf > > > > > o/lsr__;!!NEt6yMaO- > gk!UgEi3bxNDS6ZLnXNliOvkQtMeXCTCwwSe0ToOV9UMD > > > > > 54R3w20E_CXC5-bVuZr-c$ > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Lsr mailing list > > > Lsr@ietf.org > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ls > > > r__;!!NEt6yMaO- > gk!UgEi3bxNDS6ZLnXNliOvkQtMeXCTCwwSe0ToOV9UMD54R3w20E > > > _CXC5-bVuZr-c$ > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_ > > _;!!NEt6yMaO- > gk!UgEi3bxNDS6ZLnXNliOvkQtMeXCTCwwSe0ToOV9UMD54R3w20E_CXC > > 5-bVuZr-c$
- [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-ori… Christian Hopps
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Jeff Tantsura
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Ketan Talaulikar (ketant)
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Peter Psenak
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Dongjie (Jimmy)
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Acee Lindem (acee)
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Acee Lindem (acee)
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Les Ginsberg (ginsberg)
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… John E Drake
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Jeff Tantsura
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Aijun Wang
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Aijun Wang
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Gyan Mishra
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Ketan Talaulikar (ketant)
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Les Ginsberg (ginsberg)
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Christian Hopps
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Aijun Wang
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Gyan Mishra
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… 王爱俊
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Les Ginsberg (ginsberg)
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Christian Hopps
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Aijun Wang
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Aijun Wang
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Les Ginsberg (ginsberg)
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Aijun Wang
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Les Ginsberg (ginsberg)
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Peter Psenak
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Aijun Wang
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Peter Psenak
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Robert Raszuk
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Aijun Wang
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… John E Drake
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… John E Drake
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Aijun Wang
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Aijun Wang
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Aijun Wang
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… John E Drake
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Aijun Wang
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… John E Drake
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Christian Hopps
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Acee Lindem (acee)
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Baalajee S (basurend)
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Ketan Talaulikar (ketant)
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Ketan Talaulikar (ketant)
- Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix… Christian Hopps