Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

"Acee Lindem (acee)" <acee@cisco.com> Thu, 11 March 2021 19:48 UTC

Return-Path: <acee@cisco.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 81B5C3A1024; Thu, 11 Mar 2021 11:48:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.618
X-Spam-Level:
X-Spam-Status: No, score=-9.618 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=YUto0rNN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vGJsC4nX
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 j_xpMymyj_nS; Thu, 11 Mar 2021 11:48:11 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F973A100D; Thu, 11 Mar 2021 11:48:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=286334; q=dns/txt; s=iport; t=1615492091; x=1616701691; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Alplt/n5MotmtiEG0YUtby3upC0bLNNpH1z1U8l62TQ=; b=YUto0rNNJIJ02yAxwyuDUBNwu9NMbl7TGJ/lKVUmlymSqb1o07QqWAXv V+X7wBYjAZ6X90xfPuKff1loPy6qeEh0aIeSOXhuTkrI424MwmbXtXOUu DRiyHuXf2LbDUSVEeNeQAu/mV7I+tP8IfEI1oQHuKwc8WkP612rm86L2B 8=;
X-Files: image001.png : 164752
X-IPAS-Result: A0DfAgALcEpgmJJdJa3CbggDAg8DBgQVAQECAoZEhws6hEC8KJFS
IronPort-PHdr: A9a23:Vfgz3x3yH081GZ/rsmDPW1BlVkAck7zpIg4Y7IYmgLtSc6Oluo7vJ 1Hb+e4FpFDMVITfrflDjrmev6PhXDkG5pCM+DAHfYdXXhAIwcMRg0Q7AcGDBEG6SZyibyEzE MlYElMw+Xa9PBtaHc//YxvZpXjhpTIXEw/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oK xDjpgTKvc5Qioxnec4M
IronPort-HdrOrdr: A9a23:L2BZPqid3DeKrmGhxi5bMzjHBXBQX5hx3DAbvn1ZSRFFG/Gwv/ uF2NwGyB75jysQUnk8mdaGfJKNW2/Y6IQd2+gsFJ+Ydk3DtHGzJI9vqbHjzTrpBjHk+odmu5 tIW5NVTOf9BV0St6nHySGzGdo43Z2j+Kenme/Rwx5WPH5XQotLhj0JbTqzOEtwWQVAGN4dHJ 2T+sJIq1ObCAoqR+68AWQIWPWGms3TmPvdEF87LjMEyC3LtzOn77bmDwOVty1/bxpjyaovmF K16DDRyb6kt5iAu3rh/k/Vq69bgd7wjuZEbfb89vQ9DhXJpkKWaJ96W7uE1QpF4N2HzFoxit HDr1MBEq1ImgnsV1q4qxfsxAXsuQxGgxSJpDPo4gqAneXDSD03EMZHj45CGyGplnYIhs1206 5AwguixvxqJC7Ahyj06pzpUBxnhyOP0AIfuNMTlHBWXM8ibqZQp+UkjTpoOaoHdRiKjLwPIa 1LNoXx9fxWeVSVYzTypW902uGhWXw1A1OvXlUCktb96UkUoFlJi28jgOAPlHYJ85wwD7Ne4f 7fD6hunLZSCucLcKNGAvsbS8ffMB2OfTv8dEapZXj3HqAOPHzA77Tt5q8u2e2scJsUiLw/hY rGS1EdkWIpYUrhBYmv0fRwg1XwaVT4eQ6o5tBV5pB/tLG5bqHsKze/RFcnlNblrO4YBsHdRv avKJNbC/LuNgLVaMF09jy7f6MXBWgVUcUTtNp+cUmJuNj3JorjsfGecPu7HsuqLR8UHkfERl cTVjn6I8tNqmqxXGXjvRTXU3TxPkj2/Zd6FrnG7/EeobJ9b7Fkg0wwsxCU98uLITpNvugdZ0 1lOo7qlau9uC2x5mbH72JgPxJHFUZL6LD8U3dHzDV6d3/cQPImgZGyaGpS1HyIKltUVMXNCj NSoFxx5OaqNZCK3DsjDNimK2qeiHMWqBuxPs8hs5zGwf2gVoIzD54gVqA0KB7CEAZtnx127E 1ZbhUfe0PZHjTyqKmsgZAOHtvDf91kjArDG78OlVvv8WGn4eAmXD8yQiOnW8//u3deexNkwn lKt5I5rJXFszC1Mmc7iPk/KzR3GRSqKYMDKh+EaoVSkq3sYydqQw6x9GanoiB2XHb2/EMPgW GkCiuYdZjwcwZgk0Ed9Lr2+1VpcWjYRWZMUzRRtI1wEnmugAcv7caCerez32yNalEL3+EaN3 XfbSEPJx51rurHpiK9hCyPDjEvyJkoI4XmfcceWqCW1XW3JIKSk6YaW/dS4ZZ+Ldjr9vQGSO SFZmauXX/FIvJs3wyevXA+PiZo7HEijPPzwRXghVLIlkIXEL7XIF58QascLMzZ52/4R+yQ2J E8id4up+O/PiHwbdGBoJunIgJrO1fWoWSsSfsvpo0RtaUutKFrF52eSCDWzhh8rVwDBdaxkF lbTLVw4bjHNIMqd8sOezhB9l5skNiUNkMkvgH/H+dWRyBjs1bLe9eSp7bYo7smBUOM4BH9Pl SS6CVR9fbIVSnr789QN4sgZWBNLEQs4nVr++2PM5DKAAKxbudZ4R60NGS+fLI1ctnKJZwA6h Jhp9eGkO+ce3CmhETevT5nLrlP9GjiS8WoGw6IEfNJ9dv/OVnkuNrc3OejyDPsDT28YAAEgI cAc0oaZMFKkCMjg406yTLacN2+nms1119FpSh6nVvs0JW86GjVHUtaIRTU668mKQV7IzyNl4 DZ6uCW23T2/Shd1ZTCHElWeMtSG9J4dPmAEw5+bc4KvLCp+KIzgiNMJBc2ZlRM/QzA4w==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,241,1610409600"; d="png'150?scan'150,208,217,150";a="652929988"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Mar 2021 19:48:08 +0000
Received: from mail.cisco.com (xbe-rcd-006.cisco.com [173.37.102.21]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 12BJm3fZ003737 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 11 Mar 2021 19:48:06 GMT
Received: from xfe-aln-001.cisco.com (173.37.135.121) by xbe-rcd-006.cisco.com (173.37.102.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Thu, 11 Mar 2021 13:48:02 -0600
Received: from xfe-aln-003.cisco.com (173.37.135.123) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Thu, 11 Mar 2021 13:48:02 -0600
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Thu, 11 Mar 2021 13:48:02 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bZnkQiTsdgzbRmVi3R45SlfSUINj2iMQ5/Ld+u/MVQib3brkMiUDp1eTGfAVIXNyaBxnYpV527Dk/6NLVHEWa+6sB2YOjX0CkB8MS7g2A2N/qe5NkayqQJnLlOo8e9J4Cr4ZArO57Q4+1/Z9hvlpw0WysKI5vlIrL32DVeTpw30d5pWg5Exbnz5xSJKqLx1OVfMixzXuQMpc7lRTNx/mIa55WUGo+z9RasKE/aeox2P44zurpsAs6le6NPdk179UmJ0pIZ0RC7OWrICgeYe1N3+s3WbtkMk3njsAA0hGCf77nhk4E0J3mYg9rl4wqKQdwv3JiXxHUmtIc0hud+QVjQ==
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=oeDwuyty0UUEgEU9pYhlx87/V417XvZSu2zGNnyEMJs=; b=fZjl52CpTDuLSRPtU3aHmau6+aOaN1bed625Rj/t4DgkTTFTRwq/ECrztK97nPxo5EUvET9IaTBx0hr1/tR3osUKgLzwOxzN6974KyYx6ucHcblrG3LNx+FlxUTfHUjUIA7b6v+YxINOp6xjK+TXDr4Lv41MwtwiKZqR8CBfmL82ve1IdJ9A7qrB1arAiDNXQYKwYxjzeQdpY5zmvCailMGeKQkfLIJKRPctnmfORw7lvRBhwsp0PUFGYEuwHi1eDqdJ8XSdqCt52moLjvjpfNM4IJbcbHtZP6XHzRx9O62zh5nS117tdij3F8rwrMv9IADibvetKcfJNTJ390K7xg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oeDwuyty0UUEgEU9pYhlx87/V417XvZSu2zGNnyEMJs=; b=vGJsC4nXxuiiOLQN+MODHhG+MUUsphD6ygGIycYBp66UIJk/otvx7pRnEeu4rHQlijXmpn+2IvmhhZuYBQ/EKNFXm0SQVMIh40EFMmB+OOC7JuSWxqAenTpIYXqnpHqpURdnKDHck/F1+5sql5ApcqncEkeYtcq/j8/+1iOj/NU=
Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB3160.namprd11.prod.outlook.com (2603:10b6:a03:1b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.23; Thu, 11 Mar 2021 19:48:00 +0000
Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::a053:fad0:cf70:98b6]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::a053:fad0:cf70:98b6%4]) with mapi id 15.20.3890.037; Thu, 11 Mar 2021 19:48:00 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
CC: Aijun Wang <wangaj3@chinatelecom.cn>, draft-wang-lsr-prefix-unreachable-annoucement <draft-wang-lsr-prefix-unreachable-annoucement@ietf.org>, lsr <lsr@ietf.org>
Thread-Topic: https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05
Thread-Index: AQHXFHbdPXq3oeG8SU+kbxdWp1pdYqp6e9yAgABdUoCAA8lRAIAAXCGA///jfoA=
Date: Thu, 11 Mar 2021 19:48:00 +0000
Message-ID: <8D6FA7ED-E055-4EA5-9E78-00DBB82D5FB6@cisco.com>
References: <CABNhwV2=HTRYG5PTgiGYanm8LeT1HYcrPKQ4R4TQHZ-GO9ecJQ@mail.gmail.com> <439DD1F9-9924-405F-9FBD-6704D85B05D6@cisco.com> <CABNhwV3ky4nbYxo7qLowu0GyHpSYRKWdTQ3y-uQpvU-p0bskww@mail.gmail.com> <0E39A8D4-547D-482C-BD01-4A8CDE48324A@cisco.com> <CABNhwV0FhouRWmNKn4xjf=Hz7D0gP=px41506_1+JKmHKKz_xA@mail.gmail.com>
In-Reply-To: <CABNhwV0FhouRWmNKn4xjf=Hz7D0gP=px41506_1+JKmHKKz_xA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.46.21021202
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [136.56.133.70]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 09fb072d-81db-4180-c648-08d8e4c693cb
x-ms-traffictypediagnostic: BYAPR11MB3160:
x-microsoft-antispam-prvs: <BYAPR11MB3160E646C6FD92819978F507C2909@BYAPR11MB3160.namprd11.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: /CrpWVpcboqCDW7f2DSyRuGjNqTIXv/6E++poNfZXwjfD/xAtmuu9Pqt3MN8jiBGxO3aLPIjM+0nQThMPuu/RXSCAs9bvtUFsO2V+VAMPsVnAwoxXhN3+GBbm0D26gdSznnDNwfbVZerSuVKLdzFLQtYt2uHsQLrq0hqhZcMgmMRKK3+jEufft8BFLCMzzxUeXzeBKhNKJUDq1wwBExt1dX+1GxIdXmlLJ9pm64r/v7aKRyrS8PMltzR0MKciNlRKRTMvW0q3Ga4YC8xvmnFR4G2LPiNB/KSa+bWzuveTld6+oQ5V/L2C+hfVv0DMAjSBUXsuJJti0xaZ0PAS5mRmnbr3WV1tMNBJCQmvKSUWz2qJuxvrDGqZTrbhrxPH3TyZSplaEtRK10DvupTz5yrYKWrKPIoYzwPAKQEnU9Oke8UeTc4WKkKMXcDVT2gBtiTo4vS5afimkjXi6QRBlp20xDjsIBFx+B3a39atGqIZAB+19wx3oDOdaCsAp/pEm6RQu9QbAP6RtnPsde6jSEruQIMGTilBebCD8AUpgji3uycEcdnmZqHp3siEQU1u0tceWrOacllMROZfU4VUtrsKYe0fwhwtR6YF0MSKJFiynNpkfaGRF3gyXnj+1p+29ZWXULkqh0gg770V+sYLjkMUA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(346002)(376002)(396003)(366004)(39860400002)(64756008)(86362001)(66616009)(2616005)(83380400001)(8676002)(66446008)(26005)(66556008)(66574015)(166002)(9326002)(8936002)(99936003)(33656002)(2906002)(66946007)(6512007)(76116006)(66476007)(5660300002)(478600001)(36756003)(6916009)(186003)(6486002)(6506007)(966005)(54906003)(53546011)(4326008)(71200400001)(316002)(91956017)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?ZXNKL24vSWVyODE3TzZLNENKUHZLRlQ4YW82VmJpd2RSSXBFUVFUMHhMeDlY?= =?utf-8?B?bDl6NlREbkNreGtscEVHQ2NmU1R1c3pUTngvNTN1R1IxS2pob2ZWMTI0Q3A0?= =?utf-8?B?eDE1L05iaXhETDB0YjFEVmJUTFVBK1F5dE1hVk5oYXJBLzNwOWRSaUhvd1lw?= =?utf-8?B?U3cxN1hGN1IzeHdFNXVQbkxHUEIwSXlzZFlhUzFzTXJOV0ZmVHc2c3d1VXA0?= =?utf-8?B?ZUk4SzdaNTd5eWpxYnhIbE85eDV1VTM3Rk1OWmR6bGZYVUI1NEFuUG44cmIx?= =?utf-8?B?Mzl6VE40ZVpldms5bi8vMXZYZUNWdUdDV0hndTllc0M4bHZwWDAvS200TThx?= =?utf-8?B?SzZ1Zy9DNldZMkRad3dRcEorZnV3MzVSaVJyOENtT3VkeEJCcVlqYW91Ylcv?= =?utf-8?B?M01Rb0Fmc3ZaWHpzSUZyeWRIMXg0bUNKZXNkcnFuTW12VHh3TXp4R1daYmFo?= =?utf-8?B?ZWpHYlFlTEcvbE1GQ3N1bzNacFAwZHBGOTM1SjcxTzdqK0NFQjFISnlIUm5N?= =?utf-8?B?ZjJSNGR2VFd2dE84Q3lYY2g4b2dvdmpuOFdiUHgvbnRYWW9OYWI3WTBONU05?= =?utf-8?B?WkhxQjFGM1NCT0NoZXloUFJRc1V2SzRlUDgzK3RHNVVhTzdtY2NrcGF5VllR?= =?utf-8?B?dnZTenRJUFJZUDkweDdFaEZmbVJrVzc5NGVqUTcrcjd4aWg1R2xHYTJ5T00r?= =?utf-8?B?YklQdU5iODNkbWdUNFhXTGxSK2hJTklIdkR2S3VJQzRVTHRFaUs5K3ozMkVB?= =?utf-8?B?d1c0bHpFTmV5OWRsU1dFY1JBSnE0ZXBzZy9aSytMZU1ZN1Ezb2Y3UU9sd3hr?= =?utf-8?B?SXBnT0IrWlQyUW5xZXM2YlpuWUlEWWQzUFUySGY4ZFBDUmx1eTFaM0htQ3lQ?= =?utf-8?B?U21WZ1lIZHZ6MnJ6bTNTRHB4SVdHYzZhZ0RTR1lVN0w4UnR4SHRSOG5VNEZM?= =?utf-8?B?a2Z4NzVJWHJrK0pXcTZDeVpydDcrd3k0V2kxQk8wNzlwQjRNdkFic3daeUZY?= =?utf-8?B?RTFDbkIweWdnUnBTWDFFbkQwY0RybTNFQWZsK3JVZ0poTnF3Mm1RVWxSMkMy?= =?utf-8?B?QkwwN3FpamVhd0tYYTBBNEtzKzc1T2ZuNWNmeW1WNjZuVzAvR2s2OW9KVFVu?= =?utf-8?B?aXVwL1l1REZHMGR1VVhGNjRMQ0lkWlpkTk43Z3Fua3Ryd2tKTjVWeFMwNHMr?= =?utf-8?B?NW5ia0d1WFZsMFl6VWpuRGFTcDJSSUl5MVpWNlpraFp1WmNYTE93NHErRTFG?= =?utf-8?B?S0VkaktFV0pOc3VsY3g2MHJBYW94R2xKTmtFT1plUk8xY0xwZE1DRDF3QXMr?= =?utf-8?B?SFFpQTh1Vi9LYXNWTkZiOUw5WVljVjk2MDRRZEFFTnBiL1dwUWNqZ0xNS0Vn?= =?utf-8?B?cGpSeFhaM1c0V3QyTzk5UzFTWGFWV2FJS05lRWxuVHNIdCtzQUxtZWFkcjh4?= =?utf-8?B?ZWhWOEdzUkNYTEdldEQvRGhjYkVTWXVOSmg1VWpLVmgzSktXTWE0cFNqcXZH?= =?utf-8?B?UGtodEFPSWRncWdZSXBQbDRuZGFSUDJFdlpONWpMdWVsRTY1WDZyS0o2dEVE?= =?utf-8?B?NjZlay9rbnNTWVI5K2JxOTdhNnpiVlF1U0ZaaVpDRjdPMW5BbmFJMHpCT3Rv?= =?utf-8?B?T01LNnRzN280WlZocllISHZtTnE2TFoxbFNjUCtWM1V1enJwalJWTVlDSHAv?= =?utf-8?B?bDBvNTczUzZjQ2hTSEYrNjRvM0Y1U2UvcEJyeW5pVGlBeHU2akc3dDdpTyth?= =?utf-8?B?TVl3WmQyUEdLbGh5azBEZ0Zra3NWQnh2M0F6V3hkTmJLWnBKelROeTJsaitZ?= =?utf-8?B?aUk1RG9KTWhoREpGT0x4dz09?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/related; boundary="_004_8D6FA7EDE0554EA59E7800DBB82D5FB6ciscocom_"; type="multipart/alternative"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 09fb072d-81db-4180-c648-08d8e4c693cb
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2021 19:48:00.5788 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: JQAV8XRRj0bDUXr0e155g36BG65CJBqVKfXyGXXPYkMn/RKIbYe8xClZMHzLAjLN
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3160
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.21, xbe-rcd-006.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/MO22zd_YNHOlG-Rbs205j1nggzw>
Subject: Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05
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, 11 Mar 2021 19:48:15 -0000

Hi Gyan,

I think we are starting to communicate but there are still some problems.

From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Thursday, March 11, 2021 at 1:27 PM
To: Acee Lindem <acee@cisco.com>
Cc: Aijun Wang <wangaj3@chinatelecom.cn>cn>, draft-wang-lsr-prefix-unreachable-annoucement <draft-wang-lsr-prefix-unreachable-annoucement@ietf.org>rg>, lsr <lsr@ietf.org>
Subject: Re: https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

Hi Acee

Thank you for your comments.

Answers in-line.

Thank you

Gyan

On Thu, Mar 11, 2021 at 11:01 AM Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>> wrote:
Hi Gyan,

I guess you didn’t understand my first PUA question. See inline.

From: Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>
Date: Monday, March 8, 2021 at 8:11 PM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>
Cc: Aijun Wang <wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>>, draft-wang-lsr-prefix-unreachable-annoucement <draft-wang-lsr-prefix-unreachable-annoucement@ietf.org<mailto:draft-wang-lsr-prefix-unreachable-annoucement@ietf.org>>, lsr <lsr@ietf.org<mailto:lsr@ietf.org>>
Subject: Re: https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05



On Mon, Mar 8, 2021 at 7:37 PM Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>> wrote:
Speaking as a WG member:

Hi Gyan,

The first question is how do you know which prefixes within the summary range to protect? Are these configured? Is this half-assed best-effort protection where you protect prefixes within the range that you’ve installed recently? Just how does this work? It is clearly not specified in the draft.
 Gyan>  All prefixes within the summary range are protected see section 4.


   [RFC7794] and [I-D.ietf-lsr-ospf-prefix-originator<https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05#ref-I-D.ietf-lsr-ospf-prefix-originator>] draft both define

   one sub-tlv to announce the originator information of the one prefix

   from a specified node.  This draft utilizes such TLV for both OSPF

   and ISIS to signal the negative prefix in the perspective PUA when a

   link or node goes down.



   ABR detects link or node down and floods PUA negative prefix

   advertisement along with the summary advertisement according to the

   prefix-originator specification.  The ABR or ISIS L1-L2 border node

   has the responsibility to add the prefix originator information when

   it receives the Router LSA from other routers in the same area or

   level.



Acee> So, the ABR will only know about missing prefixes that it has recently received? What if the prefix is already missing when the ABR establishes adjacencies on the path to the PE? What if the prefix is being permanently taken out of service – then this negative advertisement will persist permanently. What if there is an unintentional advertisement in the summary range and it is withdrawn? How do you decide whether or not to protect a prefix with in the range?



 Gyan>  In section 6 of the draft under implementation considerations we have a MAA (Max Address Announcement) threshold value that is configurable.

    1.  If the number of unreachable prefixes is less than MAA, the ABR

   should advertise the summary address and the PUA.



   2.  If the number of reachable address is less than MAA, the ABR

   should advertise the detail reachable address only.



   3.  If the number of reachable prefixes and unreachable prefixes

   exceed MAA, then advertise the summary address with MAX metric.

       If a prefix is already missing when the ABR establishes adjacency on the path the prefix is not in the lsdb and so a PUA would not be sent for a prefix that is unknown to the ABR.  Any traffic sent to that bgp next hop would still be impacted as this is an adjacency forming timing issue.  We will have investigated this issue with the authors and are thinking of maybe a delay timer after the adjacency is formed as to when the PUA mechanism becomes activated that we can add to the considerations section.

So once an intra-area prefix within the range is reachable, you’ll maintain semi-permanent state that it is going to be protected by the PUA mechanism? Prior to that, it will not be protected? That is what you are implying. All these details need to be specified.






When the ABR or ISIS L1-L2 border node generates the summary

   advertisement based on component prefixes, the ABR will announce one

   new summary LSA or LSP which includes the information about this down

   prefix, with the prefix originator set to NULL.  The number of PUAs

   is equivalent to the number of links down or nodes down.  The LSA or

   LSP will be propagated with standard flooding procedures.



   If the nodes in the area receive the PUA flood from all of its ABR

   routers, they will start BGP convergence process if there exist BGP

   session on this PUA prefix.  The PUA creates a forced fail over

   action to initiate immediate control plane convergence switchover to

   alternate egress PE.  Without the PUA forced convergence the down

   prefix will yield black hole routing resulting in loss of

   connectivity.



   When only some of the ABRs can't reach the failure node/link, as that

   described in Section 3.2<https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05#section-3.2>.2>, the ABR th.at<http://th.at> can reach the PUA prefix

   should advertise one specific route to this PUA prefix.  The internal

   routers within another area can then bypass the ABRs that can't reach

   the PUA prefix, to reach the PUA prefix.

The second comment is that using the prefix-originator TLV is a terrible choice of encoding. Note that if there is any router in the domain that doesn’t support the extension, you’ll actually attract traffic towards the ABR blackholing it.
 Gyan> I will work with the authors to see if their is any alternative PUA process to signal and detect the failure in case prefix originator TLV is not supported.
Acee> Note that in the case of OSPFv3, the prefix originator TLV is a Sub-TLV of the Inter-Area Prefix TLV advertised in the E-Inter-Area-Prefix-LSA. If there are any OSPFv3 routers in the domain that don’t support this functionality and receive traffic for the protected prefix, they will actually route it towards the blackhole.
        Gyan>> If the OSPFv3 router does not support the prefix originator TLV is a Sub-TLV of the Inter-Area Prefix TLV advertised in the E-Inter-Area-Prefix-LSA then it would use the summary address advertised by the ABR and black hole as the control plane would not converge to not use the summary on that non supporting OSPFv3 router.  Agreed.  That support dependency we will add to the considerations section 6.

It is worse than that. For OSPFv3 routers that don’t support this extension, the E-Inter-Area-LSA will attract blackhole traffic since it will be rightly treated as a reachable more-specific advertisement.


Further, I think your example is a bit contrived. I’d hope that an OSPF area with “thousands” of summarized PE addresses wouldn’t be portioned by a single failure as in figure 1 in the draft and your slides. I also that the option of a backbone tunnel between the ABRs was removed from the draft since it diminished the requirement for this functionality.
 Gyan> This is a real world Metro access edge example as the impact is customers that have LSP built to the down egress PE that has not failed over.  In this scenario their is a Primary and Backup PE per Metro edge which is typical for an operator.

The workaround used today is to flood all /32 next hop prefixes and not take advantage of summarization.  This draft makes RFC 5283 inter area FEC binding now viable for operators.
Acee> Or add a reliable intra-area link between your ABRs. Or, as a backup, a tunnel through the backbone area (as was previously in the draft).
        Gyan>  The issue is not redundancy.  The issue is when summarization is used  as the component prefixes BGP next hop recursive to the IGP are now hidden and with MPLS RFC 5283 inter area LSP use case, the failover is broken.  It’s not just faster convergence it’s any convergence as the traffic black hole dead ends on the ABR and cannot build the LSP to the egress PE.  Please see the diagram below in the slide deck it details this special use case. The LSP ends up dead ending  black hole on the ABR once the FEC LPM goes away for the next hop when the PE has a link or node failure.

[cid:image001.png@01D71685.86C5F260]

I don’t why the ABR couldn’t stitch the LSPs through a different path as long as that path is part of the non-backbone area. I simply suggested providing more redundancy in your non-backbone area. Though not shown in your picture 😉 I see no reason why it wouldn’t work.

Thanks,
Acee

Thanks,
Acee


Thanks,
Acee

From: Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>
Date: Monday, March 8, 2021 at 6:57 PM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>, Aijun Wang <wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>>, draft-wang-lsr-prefix-unreachable-annoucement <draft-wang-lsr-prefix-unreachable-annoucement@ietf.org<mailto:draft-wang-lsr-prefix-unreachable-annoucement@ietf.org>>, lsr <lsr@ietf.org<mailto:lsr@ietf.org>>
Subject: https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05


Acee.

Please ask the two questions you raised about the PUA draft so we can address your concerns.

If anyone else has any other outstanding questions or concerns we would like to address as well and resolve.

Once all questions and  concerns are satisfied we would like to ask for WG adoption.

Kind Regards

Gyan
--

Error! Filename not specified.<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike<https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
Silver Spring, MD

--

Error! Filename not specified.<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD



--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD