Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05
Shraddha Hegde <shraddha@juniper.net> Thu, 11 March 2021 18:16 UTC
Return-Path: <shraddha@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 625BB3A0C20; Thu, 11 Mar 2021 10:16:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.357
X-Spam-Level:
X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=IWoqEdYY; dkim=pass (1024-bit key) header.d=juniper.net header.b=YpIEhqRs
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 WF1H1bVJZMLm; Thu, 11 Mar 2021 10:16:21 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 CE19A3A0B9E; Thu, 11 Mar 2021 10:16:21 -0800 (PST)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 12BIAOWl012513; Thu, 11 Mar 2021 10:16:10 -0800
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=U1OneLvIRKh45oOBFwxXps/b2Ldpa/T74QBZIk/aKNM=; b=IWoqEdYYB+am5eoNyKZLQ7QVotrYKqpQaa69ObYmhzuQzDPVg2RNMNzkYS6+nY+L49Xy +2liPSj5JfDDMJR2aJl2i0830uVlqgeu7ksFOL8gj4KcfpVsuffs6DEAWPH6vvxuVf5c CJHrrdXAS0RsLiDqCwjE8lXpaZDvoliq3no/htVzw3di3Zyh1F8EW8uWRe9uHqaHLdfu WrdLF+0PiqRz1PtVpj27w+frtUauKzogUfYkXJvo/7dNKDYtKeO2vyLkmGGlpYQQ5aa+ KeP/fzwOHQyvqgwYZyAq0HUxwLrCp73R55+c5R6+al5+VK1bFidVUKWtpeS4MqSDVZzz 9Q==
Received: from nam02-dm3-obe.outbound.protection.outlook.com (mail-dm3nam07lp2049.outbound.protection.outlook.com [104.47.56.49]) by mx0b-00273201.pphosted.com with ESMTP id 377390jbjs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Mar 2021 10:16:10 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M2GGd4EVMgqiRHnuJfMB05ZgQ8itwx0s/euYJ20flnHVBIQpzFfz1Nh1asPQm0aQYp0tlgFvbsnQXADMBjAcARL4go3iIWVJQA0vOQ+G6ftWy3WN01467dKaY39wzja5H+z3Z02FctKDzhwCtIVaunbu3XmM4EzZnt/IZtPpMA8KfSyaWrqQepT2LH9fI44CbZAe0LWgfS9YgM93zz9B6Go6l5RxtRefwRD5/YS9j9Pmbbfi30GEdvUlayYa/2RpiuB8chHCY2j+rBm7o682muTfyGbltlyOBQZGetECbZKcgO66W1GF4HTieVyFnUShJeXBaLh3zhA/W+I0QELjAA==
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=U1OneLvIRKh45oOBFwxXps/b2Ldpa/T74QBZIk/aKNM=; b=N2kAkzQBsLQFInFOumcHyXPZhtrdao+rccrr8LIYOEv9gQ1kQdwNY9gvJtpSooD0KPNSLJRp+baMMXDrAPTt0gw2u2sUDS83+vg0EblYdGdveWL0BP5wQffNlD0/PnfClcx04wno7xyLJKJA+YyPcdZBLVwuGRFWpbelE4tn6PMMTgjlVevSmHYt80Xwfj3BaI+2ApuUVbfyt2A6THgQKqJbOA4ijjVozijhobXPTG9r/x4anYZwgOGtLKKvvm9FWOQKNKpNJnWfOqYKINafSQxMAIRcoj+MBO5ku51a8hWbL+sBqq2J+epEuZEGPBS0pm1BwjmMscLGqQK7LOo6tw==
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=U1OneLvIRKh45oOBFwxXps/b2Ldpa/T74QBZIk/aKNM=; b=YpIEhqRsrfAIw9db0uiOfE6iY9f30OcxD9S6UOkL1R1gVEe1jOm5/+jsC5oGrDN4eidQLNzgGG+8W/yJjOyiUMBL7l4CtkhbRT1FlBq4I6OrfpNfUtODmnW4p6aWJ6m11pNFWUjRDRh0644KTqPXcs72hXwOTzXK0WH6dlgJrQo=
Received: from CY4PR05MB3576.namprd05.prod.outlook.com (2603:10b6:910:52::22) by CY4PR05MB2918.namprd05.prod.outlook.com (2603:10b6:903:c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.10; Thu, 11 Mar 2021 18:16:08 +0000
Received: from CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::21b0:e360:27ce:c548]) by CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::21b0:e360:27ce:c548%7]) with mapi id 15.20.3868.041; Thu, 11 Mar 2021 18:16:07 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>, Robert Raszuk <robert@raszuk.net>
CC: Gyan Mishra <hayabusagsm@gmail.com>, Aijun Wang <wangaijun@tsinghua.org.cn>, Aijun Wang <wangaj3@chinatelecom.cn>, Tony Li <tony.li@tony.li>, lsr <lsr@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>, draft-wang-lsr-prefix-unreachable-annoucement <draft-wang-lsr-prefix-unreachable-annoucement@ietf.org>
Thread-Topic: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05
Thread-Index: AQHXFHbjhzojByjuCkaO//U0eYWwQap6xlEAgAAEZQCAAADeAIAACTKAgAAmOYCAABPynYAABIWAgABm2YCAAAJVAIAAAfGAgAACy4CAAAICAIAABNmAgAOR0mA=
Date: Thu, 11 Mar 2021 18:16:07 +0000
Message-ID: <CY4PR05MB35765902297C9BB51D34EA11D5909@CY4PR05MB3576.namprd05.prod.outlook.com>
References: <22FDE3EA-B5D1-4E4D-B698-1D79173E8637@tony.li> <6E0281D2-7755-499A-B084-CA8472949683@chinatelecom.cn> <D6B0D95F-68AD-4A18-B98C-69835E8B149B@tony.li> <018801d71499$9890feb0$c9b2fc10$@tsinghua.org.cn> <CABNhwV2SpcDcm-s-WkWPpnVLpYB2nZGz2Yv0SfZah+-k=bGx4A@mail.gmail.com> <BFB3CE24-446A-4ADA-96ED-9CF876EA6A00@tony.li> <CAOj+MMGeR4bodbgpPqDCtLZD6XmX6fkjyxLWZAKa4LC2R1tBzg@mail.gmail.com> <ecf2e8b4-fdae-def6-1a29-ec1ae37f5811@cisco.com> <CAOj+MMFSEqVkM62TDAc6yn19Hup+v-9w=kiq_q6dVn39LcOkqQ@mail.gmail.com> <fdf0e62a-21fa-67e9-811d-5aa8749bb077@cisco.com> <CAOj+MMGqab_MSeZuwu0jLpCiDoZrcjnjebScscULsvnJt4_Sgw@mail.gmail.com> <2b2e9a39-ee2d-ab1c-2d59-ff5847c943e8@cisco.com>
In-Reply-To: <2b2e9a39-ee2d-ab1c-2d59-ff5847c943e8@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.6.0.76
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-03-11T18:16:04Z; 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=0d4fc761-ac58-4b44-9cb7-8e298fbd94da; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [116.197.184.15]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 4e2ad66b-ae3a-41b1-0313-08d8e4b9bdeb
x-ms-traffictypediagnostic: CY4PR05MB2918:
x-microsoft-antispam-prvs: <CY4PR05MB2918A7FEE39A236E11847A98D5909@CY4PR05MB2918.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: nOsH3QClQf0MDMfKEzrmmO3HKHj6vY78zePW+1YQS23rjNe3ZbJSVODieWVHLax0k7QFzwu61eI09JkfJMH3kgVso3nprr5y90jt/1WHnkyNtyV87C8VGbJKm3Cb+o/r1EZ1ycuUIEm7FL6s8zeh3zMINlRSYivEnlkSLfpQlp/ZGfGYnyCz/oIJ8/jruizzF7qdTWJ7VyyuL6mcucPNZg7/z005U8kmm19+tFXvmvI4G3IcfN/EtiCrstWvbr8bCM9eBzxfxmUlXa4t9MlDY0JZO85JIsRABeow8AOS3+/XOP5jubeJxD5hQMgdWRNa4kf10hX6FndBTBhO6a+P3hTssG60hG/LXRPZxejlR6pVnAhE85xtlsKbPSILfY0el2ZUXWI630ielpb0BQ02U/JTDER9O2iLSSvFPyf02OHr9fyTH+fuilUdv/FYez4fPBM7E9xBMaGqbYABDg2yFcsUNi+vckUtaNrJJ3AHXUSWUBUyUt/zEaxcbYZhel1Gmixx9i2cFHCBXAwDQHHjgyxInMCImq+qDnWJHmo2tKPNcxGS8afLBR/V60lPbxnUA0zvlFy5Bqi5uWgaBDBbK9JAE1SH6RGRQL4hITjUJbDrF/UhYfj2U7Nyp1Ni+q1o/qzh+ttDy7sO2uhIg+wjWw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR05MB3576.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(376002)(346002)(396003)(366004)(478600001)(52536014)(5660300002)(6506007)(966005)(53546011)(186003)(7696005)(64756008)(33656002)(66446008)(66556008)(54906003)(110136005)(66946007)(66476007)(2906002)(26005)(8676002)(83380400001)(8936002)(76116006)(316002)(9686003)(86362001)(55016002)(71200400001)(4326008); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 6JabF8gd2dAv8bVy/8PJagXPx9KwpbcYYt45+sGNU9X7S+sTj+wRCqlJkWs0SeIB5M79xlu6wA8pEVIyywiU+SItyc63a4p0z6rrsP080cQx8TinWEgUG7PJLk4YkVryOCPh/7IkPWcyTWVlitJR1aqTKSawL7ty8hV5gPzmoKuMLMExlPbcC04EkGWo7SuFMK0pLjh57ZIb/JyqCDWvJ2zneKGOsukv3jrIl7u8+ontZ3zoD7oDF7xJopNBh8FnZpSMLPdfuZf1fxYQYTaUaG4Wjfo2gAYV/vFvNWgnn2Un80CH1czuzE5vCLzGg+ojNqXIPSV/ZmRWaUY7mYsVLCvphtR2Y2tu4zWZzioaCP7eIGDeOpjZYU4e6bjkCmBuebsHTzRpwVjnAhQjwsK4kCT8KKpDujLTi+6mlIFQwCIC/kIxebXa3utTuUYRRM+Z010bmz3yy/OO81RBYY1uWfD7WIV2Ut/n3eSqR+NxK6c5foKwE2P8eTmt8qkzAR5NeBURFGYbpZBPHoF3d+EDETxa1iZm5+8lrhbPGAmFZ43UQZX4JAKDGvLq+oVbgElVgrmgAZhuTQC06UuqQdiYQ2dq+X1HAcFmEfDyj8MUQlBXMwibwAu1ERYoAN4sxvz++OVPXsgfl3pKERxIa2lqqp2dT5j1sI9fX0W6Gt6fAI3e2I1rIb5a6oMpLMeGBpb2kdWUq+6BFSjBEi+oU0ObfCk+Z0BrOmTSWU7MB9EIGhnPfnprKKYgCz6dopmgZyIC3Q/PA8tgOLhQ38JtheUm7UkhmIbGIr5wIy76HTVmXKrYWuwTYL8yC50TkxyJZOHN6vDgQGgtOMx44NM+6pI3vuS7hz0tVbvtxAe/kyl5+jtjOBbm/ovzg7wzQ39JK8ls8fPtdt7W4xsvCSnKm7fIxtmB9C3/JuGtUMSzMcLZQA8C2SX8BbKj9FELrGfePBsMhU0GSRTfuQyIB1pK7NSG1ynT9KiSb8sxE+mkxkOuAAWIR9dvUhAqaAA+kZ8GM0L7LmIdYx1odHIIh2EgFLbbroQU4L6Du+BHQjAuViEjDjoDp+eS7P+HzQYB6cwBAuu6z0YZXdDjWR16+C59mPpMDklJQRRMRQQDtG/Emzsf+mu+XHvgM19hnQvbXNrOpzmGCxSEZDujHfqsBAZ+Z36HamVWfBr6EpZ3yUiOcjtPuoVNvThkhXdqSHvyCs4RHM3lG2kqq5ze+5GVZ7sz3S6q4WbC4niu3DOSrvgQTiJknFgJB2duPEy3f67WTzRVWBBHwfEgA8OV3JiEqOgDN/8+G9WUIRZyYUlydhJJGxb7xQH5qhe6MqIH5d6KMvcp7ifB
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: CY4PR05MB3576.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4e2ad66b-ae3a-41b1-0313-08d8e4b9bdeb
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2021 18:16:07.1617 (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: vLS4U6/wqC5CAdi26Ork40k5zWCcNu9fCFjCGqOupcwKHSco3qdIwfl0EzhCG/kTaIKNZi23l/G/2rMup/YVmQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB2918
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-11_08:2021-03-10, 2021-03-11 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 impostorscore=0 priorityscore=1501 clxscore=1011 spamscore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 lowpriorityscore=0 phishscore=0 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103110094
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/w81Gslu3h-ALcq4K5-xgdvt03XE>
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 18:16:29 -0000
I agree problem is valid for networks that use summarization and leaking for inter-domain connectivity. However, I don't think the solution space has to be in IGP. There are various different ways the problem could be solved. A network could deploy egress protection [RFC 8679] or anycast based egress protection [draft-hegde-rtgwg-egress-protection-sr-networks] which will ensure packets aren't dropped Due to remote PE node failure. This mechanism is faster compared to other possible Solutions because if addresses failure at the PLR and provides protection. Rgds Shraddha Juniper Business Use Only -----Original Message----- From: Lsr <lsr-bounces@ietf.org> On Behalf Of Peter Psenak Sent: Tuesday, March 9, 2021 5:07 PM To: Robert Raszuk <robert@raszuk.net> Cc: Gyan Mishra <hayabusagsm@gmail.com>; Aijun Wang <wangaijun@tsinghua.org.cn>; Aijun Wang <wangaj3@chinatelecom.cn>; Tony Li <tony.li@tony.li>; lsr <lsr@ietf.org>; Acee Lindem (acee) <acee@cisco.com>; draft-wang-lsr-prefix-unreachable-annoucement <draft-wang-lsr-prefix-unreachable-annoucement@ietf.org> Subject: Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05 [External Email. Be cautious of content] Robert, On 09/03/2021 12:20, Robert Raszuk wrote: > > > In addition you may have a hierarchical RR, which would still > involve > BGP signalling. > > Last time I measured time it takes to propage withdraw via good RR was > single milliseconds. > > > > because BGP signalling is prefix based and as a result slow. > + > > that is the whole point, you need something that is prefix independent. > > BGP can be easily setup in prefix independent way today. > > Example 1: > > If session to PE1 goes down, withdraw all RDs received from such PE. still dependent on RDs and BGP specific. We want app independent way of signaling the reachability loss. At the end that's what IGPs do without a presence of summarization. Again, I'm not advocating the solution proposed in draft-wang-lsr-prefix-unreachable-annoucement. I'm just saying the problem seems valid and IGP based solution is not an unreasonable thing to consider if a reasonable one can be found. > > Example 2: > > Use IGP recursion - Use RFC3107 to construct your interarea LSPs. If > PE there is no LSP in SRv6. Peter > goes down withdraw it. IGP can still signal summary no issue as no > inet.3 route. > > Best, > R. > > > On Tue, Mar 9, 2021 at 12:12 PM Peter Psenak <ppsenak@cisco.com > <mailto:ppsenak@cisco.com>> wrote: > > Hi Robert, > > On 09/03/2021 12:02, Robert Raszuk wrote: > > Hey Peter, > > > > Well ok so let's forget about LDP - cool ! > > > > So IGP sends summary around and that is all what is needed. > > > > So the question why not propage information that PE went down in > service > > signalling - today mainly BGP. > > because BGP signalling is prefix based and as a result slow. > > > > > > And forget BFD, does not scale with 10k PEs. > > > > You missed the point. No one is proposing full mesh of BFD sessions > > between all PEs. I hope so at least. > > > > PE is connected to RRs so you need as many BFD sessions as RR to > PE BGP > > sessions. > > that can be still too many. > In addition you may have a hierarchical RR, which would still involve > BGP signalling. > > Once that session is brought down RR has all it needs to > > trigger a message (withdraw or implicit withdraw) to remove the > > broken service routes in a scalable way. > > that is the whole point, you need something that is prefix independent. > > thanks, > Peter > > > > > Thx, > > R. > > > > PS. Yes we still need to start support signalling of > unreachability in > > BGP itself when BGP is used for underlay but this is a bit > different use > > case and outside of scope of LSR > > > > > > On Tue, Mar 9, 2021 at 11:55 AM Peter Psenak <ppsenak@cisco.com > <mailto:ppsenak@cisco.com> > > <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>> wrote: > > > > Robert, > > > > On 09/03/2021 11:47, Robert Raszuk wrote: > > > > You’re trying to fix a problem in the overlay by > morphing the > > > underlay. How can that seem like a good idea? > > > > > > I think this really nails this discussion. > > > > > > We have discussed this before and while the concept of > signalling > > > unreachability does seem useful such signalling should be done > > where it > > > belongs. > > > > > > Here clearly we are talking about faster connectivity > restoration > > for > > > overlay services so it naturally belongs in overlay. > > > > > > It could be a bit misleading as this is today underlay which > > propagates > > > reachability of PEs and overlay relies on it. And to scale, > > > summarization is used hence in the underlay, failing > remote PEs > > remain > > > reachable. That however in spite of many efforts in lots of > > networks are > > > really not the practical problem as those networks still > relay on > > exact > > > match of IGP to LDP FEC when MPLS is used. So removal of > /32 can and > > > does happen. > > > > think SRv6, forget /32 or /128 removal. Think summarization. > > > > I'm not necessary advocating the solution proposed in this > particular > > draft, but the problem is valid. We need fast detection of > the PE loss. > > > > And forget BFD, does not scale with 10k PEs. > > > > thanks, > > Peter > > > > > > > > > > > > In the same time BGP can pretty quickly (milliseconds) > > remove affected > > > service routes (or rather paths) hence connectivity can be > > restored to > > > redundantly connected endpoints in sub second. Such > removal can > > be in a > > > form of atomic withdraw (or readvertisement), removal of > recursive > > > routes (next hop going down) or withdraw of few RD/64 > prefixes. > > > > > > I am not convinced and I have not seen any evidence that if we > > put this > > > into IGP it will be any faster across areas or domains > (case of > > > redistribution over ASBRs to and from IGP to BGP). One > thing for > > sure - > > > it will be much more complex to troubleshoot. > > > > > > Thx, > > > R. > > > > > > On Tue, Mar 9, 2021 at 5:39 AM Tony Li <tony.li@tony.li > <mailto:tony.li@tony.li> > > <mailto:tony.li@tony.li <mailto:tony.li@tony.li>> > > > <mailto:tony.li@tony.li <mailto:tony.li@tony.li> > <mailto:tony.li@tony.li <mailto:tony.li@tony.li>>>> wrote: > > > > > > > > > Hi Gyan, > > > > > > > Gyan> In previous threads BFD multi hop has been > > mentioned to > > > track IGP liveliness but that gets way overly complicated > > especially > > > with large domains and not viable. > > > > > > > > > This is not tracking IGP liveness, this is to track > BGP endpoint > > > liveness. > > > > > > Here in 2021, we seem to have (finally) discovered > that we can > > > automate our management plane. This ameliorates a > great deal of > > > complexity. > > > > > > > > > > Gyan> As we are trying to signal the IGP to > trigger the > > > control plane convergence, the flooding machinery in > the IGP > > already > > > exists well as the prefix originator sub TLV from the > link or > > node > > > failure. IGP seems to be the perfect mechanism for > the control > > > plane signaling switchover. > > > > > > > > > You’re trying to fix a problem in the overlay by > morphing the > > > underlay. How can that seem like a good idea? > > > > > > > > > > Gyan>As I mentioned advertising flooding of > the longer > > > prefix defeats the purpose of summarization. > > > > > > > > > PUA also defeats summarization. If you really insist > on faster > > > convergence and not building a sufficiently redundant > > topology, then > > > yes, your area will partition and you will have to pay the > > price of > > > additional state for your longer prefixes. > > > > > > > > > > In order to do what you are stating you have to > remove the > > > summarization and go back to domain wide flooding > > > > > > > > > No, I’m suggesting you maintain the summary and ALSO > > advertise the > > > longer prefix that you feel is essential to reroute > immediately. > > > > > > > > > > which completely defeats the goal of the draft > which is to > > make > > > host route summarization viable for operators. We > know the > > prefix > > > that went down and that is why with the PUA negative > > advertisement > > > we can easily flood a null0 to block the control plane > from > > > installing the route. > > > > > > > > > So you can also advertise the more specific from the > > connected ABR… > > > > > > > > > > We don’t have any prior knowledge of the alternate > for the > > egress > > > PE bgp next hop attribute for the customer VPN > overlay. So > > the only > > > way to accomplish what you are asking is not do any > summarization > > > and flood al host routes. Of course as I stated > defeats the > > > purpose of the draft. > > > > > > > > > Please read again. > > > > > > Tony > > > > > > _______________________________________________ > > > Lsr mailing list > > > Lsr@ietf.org <mailto:Lsr@ietf.org> <mailto:Lsr@ietf.org > <mailto:Lsr@ietf.org>> <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org> > > <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>>> > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!QNHPABFYBen6qbmt6hiQ4B3EwShSGUz40c2NFKvGTCyozXP3LpTpWT2562wntcNw$ > > > > > > _______________________________________________ Lsr mailing list Lsr@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!QNHPABFYBen6qbmt6hiQ4B3EwShSGUz40c2NFKvGTCyozXP3LpTpWT2562wntcNw$
- [Lsr] https://tools.ietf.org/html/draft-wang-lsr-… Gyan Mishra
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Tony Li
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Aijun Wang
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Tony Li
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Acee Lindem (acee)
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Gyan Mishra
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Aijun Wang
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Gyan Mishra
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Aijun Wang
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Tony Li
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Aijun Wang
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Gyan Mishra
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Tony Li
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Tony Li
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Gyan Mishra
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Aijun Wang
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Peter Psenak
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Robert Raszuk
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Peter Psenak
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Robert Raszuk
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Peter Psenak
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Tony Przygienda
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Robert Raszuk
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Peter Psenak
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Robert Raszuk
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Peter Psenak
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Robert Raszuk
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Peter Psenak
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Tony Przygienda
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Robert Raszuk
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Tony Przygienda
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Acee Lindem (acee)
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Shraddha Hegde
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Gyan Mishra
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Acee Lindem (acee)
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Aijun Wang
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Aijun Wang
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Gyan Mishra
- Re: [Lsr] https://tools.ietf.org/html/draft-wang-… Peter Psenak