Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

Yingzhen Qu <yingzhen.qu@futurewei.com> Thu, 19 November 2020 08:46 UTC

Return-Path: <yingzhen.qu@futurewei.com>
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 B35023A11F3 for <lsr@ietfa.amsl.com>; Thu, 19 Nov 2020 00:46:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.078
X-Spam-Level:
X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com
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 BaC_Lb0V7cxg for <lsr@ietfa.amsl.com>; Thu, 19 Nov 2020 00:46:13 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770104.outbound.protection.outlook.com [40.107.77.104]) (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 58DC43A11DE for <lsr@ietf.org>; Thu, 19 Nov 2020 00:46:12 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RMR4RyDtOZ2VI68NVicCll3LtfQ4cKdva5yVQm/TbzmG5daQZGXyP87dHylVG5zQytob6/TGRvSDfmrtpv1Qaa2C6Rkar2EitA6JtsSwtiYlcjs696iP6/vHPV+iWxAWYUhZfrGL5qGPRj4rHmEwOIz0pKgNMCotX3EA+EEZgNnf1olAaZsG0gY66kqddb/4VVP4duy63Kx2WIfxVBSm+MvXBT4VuIqWbFVr8h9OsEGPjggQPQfRirjGSqppczUgTOSetLAulMJg+OzUEss9ezeeCvTUozlx11EZ2HMnKLBTi9hqKJUTuj+Axw+Gr3HrXTJ+o+KBGpFmF5XO1U9XVg==
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=nR7+KUvlQdvjTnhQH9f1piXBC34UvUBas/W/Strurn8=; b=UMVdOp3vGgE3fNIU4pN6YidhdagSOj1DIZ0sSlTfmXSLqqzqt8bzbilNJUEo6Q5dOrj6IS6ozV6TfvdQYDiVhVMo8shLa/8VOXj56u+4/1i7unE/ELZTctHrBkspHvs3v2Gt7kZsPUQb0iTVRJFUCkEY2Qa6kmw3ivNHSMARCFhvXHLLzx6KPvMpWUTKiQTC12b1+t266IbDdvjeXHiaPzttcsLAWfyHpumvsOofmCildCe5Ga0upk6O7z6crkXGrPgWgzxzXwgiFGQA7DDthb27QaBJGItQ0ujPYsa1+kBXt7LnOuyLIkKF3A8DgWZ93+7GYOSYSHgnSiDToQahNQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nR7+KUvlQdvjTnhQH9f1piXBC34UvUBas/W/Strurn8=; b=BywqU+jvvCzswdtL1ru+SADOcuO77prQcheQPu36QSeWomEEYpWmLNVHbi9T8vj/1tYJpRxcSiqfD7Tu6/9vKmb+3Lu8lsoc3nE8lG72KP4VhBaDugYZGwKXaduD9Rnm3LQJGzF7H0FeF48WuWjl1yRkdI5U6RZu8ysb1jgvBJ4=
Received: from MN2PR13MB3053.namprd13.prod.outlook.com (2603:10b6:208:156::27) by BL0PR13MB4289.namprd13.prod.outlook.com (2603:10b6:208:8b::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.16; Thu, 19 Nov 2020 08:46:09 +0000
Received: from MN2PR13MB3053.namprd13.prod.outlook.com ([fe80::7474:65b1:b6bf:20f6]) by MN2PR13MB3053.namprd13.prod.outlook.com ([fe80::7474:65b1:b6bf:20f6%6]) with mapi id 15.20.3589.015; Thu, 19 Nov 2020 08:46:09 +0000
From: Yingzhen Qu <yingzhen.qu@futurewei.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>, "'Acee Lindem (acee)'" <acee@cisco.com>
CC: 'lsr' <lsr@ietf.org>
Thread-Topic: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt
Thread-Index: AQHWvRIc1WSnOsceCUOqEa5V/H8ON6nNKlUAgAAlAACAACkHAP//3BqAgAFofYD//+OlAA==
Date: Thu, 19 Nov 2020 08:46:09 +0000
Message-ID: <83A5DF87-53DD-4197-8D7C-CAF2591FF34E@futurewei.com>
References: <160539745568.19790.10758399794139845841@ietfa.amsl.com> <016a01d6bca7$f8753700$e95fa500$@chinatelecom.cn> <F9DA273B-3386-4C26-ADDB-527394C22156@cisco.com> <00fa01d6bd52$3daacce0$b90066a0$@tsinghua.org.cn> <2DF4A6D0-E410-4652-977C-258A0D2950D5@cisco.com> <018101d6bd79$41038310$c30a8930$@tsinghua.org.cn> <F390C1C7-BD48-4169-AF0F-1C7A2D3DD40B@futurewei.com> <00ca01d6be1b$8c34bff0$a49e3fd0$@tsinghua.org.cn>
In-Reply-To: <00ca01d6be1b$8c34bff0$a49e3fd0$@tsinghua.org.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.43.20110804
authentication-results: tsinghua.org.cn; dkim=none (message not signed) header.d=none;tsinghua.org.cn; dmarc=none action=none header.from=futurewei.com;
x-originating-ip: [2601:646:9500:4d:da6:2acb:7a3:70]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d7a1407f-b3ab-41b0-0ae1-08d88c678fbe
x-ms-traffictypediagnostic: BL0PR13MB4289:
x-microsoft-antispam-prvs: <BL0PR13MB42890027F767E8D91B9BB5AFE1E00@BL0PR13MB4289.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6108;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: XzcowNW09VIsLxZKEWMsCyTIx4JCcX0ffQJPvHTBqQq5I78UkV98jS4NL/vGh+Kyx1DfjH/0xAtkBJ9UNq8ueTaz/IimrX7rT1+VNvmPReM5NKyyYKLxPBr0Y5LrqZTWV+dh4cb9AJpCwIH6rDD06ZcZ7anEpBuLPGgMRQ4NVKAK1hoI7BX6InGOB+Lw+QUJPfn2DpclPcg2OvdOuX9nPN+Cs44nyB4aHO4ulfgqfr72WOQO+Mj8oFkvba2SV8uGvsLBF5dRZVxjklTF3PCSKHRRaPnNmYJzhir4myKa/SIyoqQ/ESh7RlnJU1VAojo2ONyWBWW6kSPJ/8BEAczosLa4VUNLVWMZX3E21AyIYDDOkFF1emazV2wlDgHIUdlsT6V1PebtH5NGafHnq20nWg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB3053.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(39850400004)(346002)(136003)(366004)(478600001)(86362001)(53546011)(186003)(91956017)(66574015)(83380400001)(966005)(6486002)(36756003)(71200400001)(166002)(2616005)(44832011)(66476007)(6506007)(66446008)(9326002)(316002)(8676002)(66556008)(33656002)(76116006)(30864003)(6512007)(15650500001)(110136005)(64756008)(4001150100001)(4326008)(8936002)(5660300002)(66946007)(2906002)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 3kyzSsuoqdT4T4LFFYcchnGMPuKDPRBHiYYjVV9/690jkZkgDCkJta97HdfKjyR8UicORIzgIi8F1/FyGxZhC05+8Hwpip5T7/OJ2F0LDNDH3e+8Q6R14rG0kETtMG1v+in3YfKIF8GZELTPHrtXIZCDEy5D4Wq2Q8N+aMRnqbErVrDpV9okFp2lIo0fWUfCz/dcSIhXPWivjuOplW0QSyOd2LUzPwHGvG9K0WQZIXCGHP7Tz+fBzpvUauvrE9r6Y/+vSHUt2bSr1DhK4s3FXn6S2C+JM7659It3KuTA1f2kRnTdzEyXopkDt/uUiCXNHixsoD4PbcXsVyEyJzs1M1l1ZJJcMc9723/1an44jNXMg8sN5yckp6R6jRnC6yzbNGVE2rK8hKqdaeNjBqyeuqPvmgbsCOjORud+yGZeYsU0sIY7hQhqaVfTJdG9/vRWF4H3grBy2KSSNjwpHKSzHrT/5sxmjzy0Z47syCWi3NxC4wzDfvSNWX98cjU4oNLWoIs7SnjjtlJ9xSSE9s402wz7wOmV+Ys0xKonf8rM/RcDeh+pu8Yuu9qmzJY/p301z67TqgQf/n94JoQCARRkI01Qo0vDEKLa21AJpRHE6mSv4U7yxPFq+eEPITpY7QACx9X/GHIhhjuSovteviH2ppGcH400RV4+9gUi8Onlo7mVI9wlUCwg1D1+NDNaXDzO
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_83A5DF8753DD41978D7CCAF2591FF34Efutureweicom_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB3053.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d7a1407f-b3ab-41b0-0ae1-08d88c678fbe
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2020 08:46:09.2142 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: H2F/N9dC4FQB4al/ktK4RhpxKwUKX/ghUDHhSRPmb92t2F2Mv5/JoZtAyNLdU6pDiHrt9Iy9tY69gtJm6/dHxw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR13MB4289
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/yoHWF_WTKOfYR3E6NDJaDVRDwbE>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt
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: Thu, 19 Nov 2020 08:46:17 -0000

Hi Aijun,

Please see my response below inline.

Thanks,
Yingzhen

From: Aijun Wang <wangaijun@tsinghua.org.cn>
Date: Wednesday, November 18, 2020 at 6:27 PM
To: Yingzhen Qu <yingzhen.qu@futurewei.com>, "'Acee Lindem (acee)'" <acee@cisco.com>
Cc: 'lsr' <lsr@ietf.org>
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

Hi, Yingzhen:

Please see whether the replies below inline can solve your concerns or not.

Best Regards

Aijun Wang
China Telecom

From: lsr-bounces@ietf.org <lsr-bounces@ietf.org> On Behalf Of Yingzhen Qu
Sent: Wednesday, November 18, 2020 8:57 PM
To: Aijun Wang <wangaijun@tsinghua.org.cn>; 'Acee Lindem (acee)' <acee@cisco.com>
Cc: 'lsr' <lsr@ietf.org>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

Hi Aijun,


[WAJ] In your 109 meeting presentation slides-109-lsr-5-ospf-transport-instance-00<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F109%2Fmaterials%2Fslides-109-lsr-5-ospf-transport-instance-00&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658792571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=0zEyN2fX7sFk9H1yDe06BiCmZEQigkS2tlEDAtsC7qU%3D&reserved=0>, you mentioned also the similar information that should be transferred via the OSPF protocol. I think this is the direction and we can prepare for it in advance. Putting such non-routing information in one independent TLV can certainly keep the stability of IGP protocol.

Just to respond this comment here. The purpose of OSPF transport instance is to carry non-routing information for applications without impacting routing calculation and convergence. When you say “this is the direction”, do you mean using OSPF transport instance to carry application data or to use base OSPF instance?
[WAJ] use base OSPF instance is better. I think the reason to advertise the server info via IGP protocol is to let the router select the right path to server.

[Yingzhen]: The path calculation to servers is done in the base instance. Transport instance doesn’t do or impact base instance path calculation.

Also how putting such non-routing information in one independent TLV can keep the stability of IGP protocol?
[WAJ] The router can easily recognize such info when it do SPF calculation, skip some steps(for example, topology calculation) then.
And, considering the interface that connects the server to the router is always passive, would you like to put these info into Stub-Link TLV that defined in the passive interface draft?

[Yingzhen]: It’s not only about route computing, you will need to flood all the application information.

Depending on the application, this kind of information may need to be updated very often, for example CPU usage, and this will certainly have some impacts. Especially when there more applications and each of them needs to be updated at different intervals and frequencies.
[WAJ] They should all meet the minimum threshold, as also mentioned in Acee’s presentation file.

[Yingzhen]: We considered scalability issues and ways for mitigation, but I don’t think it was discussed it in your draft. Please let me know if I missed it. Also it’s not a good idea to mix flooding application information together with routing information.

Thanks,
Yingzhen

From: Lsr <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> on behalf of Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>
Date: Tuesday, November 17, 2020 at 11:06 PM
To: "'Acee Lindem (acee)'" <acee@cisco.com<mailto:acee@cisco.com>>
Cc: 'lsr' <lsr@ietf.org<mailto:lsr@ietf.org>>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt
Resent-From: <yingzhen.qu@huawei.com<mailto:yingzhen.qu@huawei.com>>
Resent-Date: Tuesday, November 17, 2020 at 11:06 PM

Hi, Acee:

From: Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>>
Sent: Wednesday, November 18, 2020 12:39 PM
To: Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>
Cc: 'lsr' <lsr@ietf.org<mailto:lsr@ietf.org>>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

From: Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>
Date: Tuesday, November 17, 2020 at 9:27 PM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>
Cc: 'lsr' <lsr@ietf.org<mailto:lsr@ietf.org>>
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt


Hi, Acee:



-----Original Message-----
From: lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org> <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> On Behalf Of Acee Lindem (acee)
Sent: Wednesday, November 18, 2020 2:47 AM
To: Aijun Wang <wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>>
Cc: 'lsr' <lsr@ietf.org<mailto:lsr@ietf.org>>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt



Speaking as WG member and longtime steward  of the IGPs:



Hi Aijun,



My opinion is that we should not overload the base IGP topology advertisements with everyone's favorite obscure use case. Hence, I think it would be a big mistake to add this stub link TLV to the base LSAs.

[WAJ] Putting the information in other regular TLVs, or putting them in LSA of one independent IGP instance(as you proposed in 109 meeting) will be more expensive. Do you agree this statement?



No – bloating the primary LSAs with non-routing information will be more expensive due to the dynamics of LSA origination and route computation.

[WAJ] what’s your recommendation then? The router can skip such information when they do SPF calculation, just need only add the information to the attached leaf router when the computation is completed. The LSA update is periodic and event driven. Advertising such information in a controlled manner does not deteriorate the flooding status.



Rather, exactly what problem are you trying to solve? Previously, you were trying to associate the passive interface attribute with a prefix and making some inference related to an inter-AS boundary (this was not entirely clear). What problem are you trying to solve? Precisely, what do you want the controller to learn (i.e., address or interface index) and what is it going to do with it.

[WAJ] Passive Interfaces are already deployed within the network in many places, as stated in the draft-wang-lsr-passive-interface-attribute-06#section-1<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-wang-lsr-passive-interface-attribute-06%23section-1&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658802564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=u1jp2Gh5FGvRsX5jpe%2FM3EAHAKB0oBtNUs4aVkR2XZI%3D&reserved=0>. What we want to know, is the position of passive interface. Previously, we want piggyback such information within its associated prefix, but after discussion on the mail list, define one new TLV to contain it and other future information may be more acceptable and extensible.



And how do identify and even define the position of the passive interface?

[WAJ] Passive interface be certainly attached the router that advertises the associated stub-link TLV.



As I stated previously, passive interfaces are not standardized.

[WAJ] if you mentioned just the term, we can change it later. Or if so, what’s other term do you recommend then?



Knowing these information, the controller can learn the inter-as links via some methods that we have discussed in another thread, can know the boundary of network, can learn the link characteristic that associated with server etc. We have also mentioned it in the draft-wang-lsr-passive-interface-attribute-06#section-1<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-wang-lsr-passive-interface-attribute-06%23section-1&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658812565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=hwjvgwEZGe4vUDzWpxPPGRnzPbXsdcAZQMkwWrUovhk%3D&reserved=0> and think it is not appropriate to expand it intensely in one LSR draft.



I disagree. Precisely define your use case.

[WAJ] which part of the introduction section is not clear enough? There are about 3 possible use cases of such information, aren’t they enough?

And, we have described one use case in detail in previous version of this draft draft-wang-lsr-passive-interface-attribute-04#section-3<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-wang-lsr-passive-interface-attribute-04%23section-3&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658812565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=7YmBswqHw%2FzTz949jph256KuSHKdRsos8d62roKxKDg%3D&reserved=0>. If necessary, we can add it back again in the next version. This is just one use case, you can also refer to draft-dunbar-lsr-5g-edge-compute-ospf-ext-01<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dunbar-lsr-5g-edge-compute-ospf-ext-01&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658822554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Go9uiHra7uSKQwbgQzMxBxq8WWQjs4%2BKZhpZrVy0ZPw%3D&reserved=0> for the detail of another use case.







Please don't try and solve the CFN problem as the requirements are not clear (anycast, unicast, impact on routing, scope, etc).

[WAJ] In your 109 meeting presentation slides-109-lsr-5-ospf-transport-instance-00<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F109%2Fmaterials%2Fslides-109-lsr-5-ospf-transport-instance-00&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658832547%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=XQXZVRYKVrYH2YeQs6zCX9hh7JgrksqZtIviIAgJPlk%3D&reserved=0>, you mentioned also the similar information that should be transferred via the OSPF protocol. I think this is the direction and we can prepare for it in advance. Putting such non-routing information in one independent TLV can certainly keep the stability of IGP protocol.



This was just an example of something that could be offloaded to a separate instance in the slides. It is not a specification.



Thanks,

Acee







Thanks,

Acee



On 11/17/20, 1:08 AM, "wangaj3@chinatelecom.cn on behalf of Aijun Wang<mailto:wangaj3@chinatelecom.cn%20on%20behalf%20of%20Aijun%20Wang>" <wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>> wrote:



    Hi, Acee:



    As discussed on the list and during the 109 meeting, we have updated the draft to reflect the comments from the LSR community.

    Please see whether you have still other concerns or not and if there is no further comments on this direction, can we begin the WG adoption call then?

    Thanks you and Peter for your intense discussions for this draft.



    Thanks in advance.



    Best Regards



    Aijun Wang

    China Telecom



    > -----Original Message-----

    > From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>

    > Sent: Sunday, November 15, 2020 7:44 AM

    > To: Zhibo Hu <huzhibo@huawei.com<mailto:huzhibo@huawei.com>>; Aijun Wang

    > <wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>>; Gyan S. Mishra <gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>>;

    > Gyan Mishra <gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>>

    > Subject: New Version Notification for

    > draft-wang-lsr-passive-interface-attribute-06.txt

    >

    >

    > A new version of I-D, draft-wang-lsr-passive-interface-attribute-06.txt

    > has been successfully submitted by Aijun Wang and posted to the IETF

    > repository.

    >

    > Name:           draft-wang-lsr-passive-interface-attribute

    > Revision:       06

    > Title:              Passive Interface Attribute

    > Document date:   2020-11-15

    > Group:          Individual Submission

    > Pages:           10

    > URL:

    > https://www.ietf.org/archive/id/draft-wang-lsr-passive-interface-attribute-06.t<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-wang-lsr-passive-interface-attribute-06.t&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658832547%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=YUL4xSfvMCJS0FOsw3YYynM1oLvKmWTbWWdKIn6JwE0%3D&reserved=0>

    > xt

    > Status:

    > https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-attribute/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wang-lsr-passive-interface-attribute%2F&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658842542%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=afbZUDIeGJwmmQ1qXOv5RG5pODeZNmV2o3al0p3%2Fx9Y%3D&reserved=0>

    > Htmlized:

    > https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribut<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-wang-lsr-passive-interface-attribut&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658852535%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=hoabrzbGGOqcAMaP5zMMZSzV%2Fs1tnio3EKwUzxiLo%2FE%3D&reserved=0>

    > e

    > Htmlized:

    > https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-06<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-wang-lsr-passive-interface-attribute-06&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658852535%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=wog8EmavtkQ3xnqQbrWoGx9w9%2Bl%2FoHr%2F%2BuQLUoWSvxs%3D&reserved=0>

    > Diff:

    > https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-passive-interface-attribute-06<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-wang-lsr-passive-interface-attribute-06&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658862529%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=7tA7h3gr%2FZ7%2BugZW4YunhBwDjhxQ6IuJL7AZZBI1wjU%3D&reserved=0>

    >

    > Abstract:

    >    This document describes the mechanism that can be used to

    >    differentiate the passive interfaces from the normal interfaces

    >    within ISIS or OSPF domain.

    >

    >

    >

    >

    > Please note that it may take a couple of minutes from the time of submission

    > until the htmlized version and diff are available at tools.ietf.org.

    >

    > The IETF Secretariat

    >







_______________________________________________

Lsr mailing list

Lsr@ietf.org<mailto:Lsr@ietf.org>

https://www.ietf.org/mailman/listinfo/lsr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658872532%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=pGBx5p%2BUvwW6WHEgEsmQSVV%2BGmIXTkeNQzZf4DFidrQ%3D&reserved=0>