IETF Logo Mail Archive

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

Peter Psenak <ppsenak@cisco.com> Wed, 15 June 2022 13:54 UTC

Return-Path: <ppsenak@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 763D4C159487 for <lsr@ietfa.amsl.com>; Wed, 15 Jun 2022 06:54:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.226
X-Spam-Level:
X-Spam-Status: No, score=-12.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.745, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.876, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, 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
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_TPQQ9Nuhib for <lsr@ietfa.amsl.com>; Wed, 15 Jun 2022 06:54:04 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751DBC159482 for <lsr@ietf.org>; Wed, 15 Jun 2022 06:53:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=926; q=dns/txt; s=iport; t=1655301214; x=1656510814; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Gc45O+Sa70Q20eNMbgtBKAtJir8Go6KlZ2H1FgUkHsA=; b=A/eShE7VIiQ3Gj7vENTwiSxtzIXFiSH7t8e2O4em3vVSenyH7L/a7NuQ l0wAFC0euxQ57aFiahKo1ajNmV0kQUg7BjLAm6hSLILqx5XokCUJZ6ul7 XnRNNay/acI5pQ4R1vrzu8MsfTCb6pL1fHAAYp2DZ7AQzfT3IlROh0BKk c=;
X-IPAS-Result: A0DDAADx46lilxbLJq1aHgEBCxIMQIFEC4N6LBKFEokAiA+ca4F8CwEBAQ9CBAEBhQMChUkmNgcOAQIEAQEBAQMCAwEBAQEBAQMBAQUBAQECAQcEFAEBAQEBAQEBCRsGDAUQNYV1hkIBAQEBAgEjDwEFQRALGAICJgICVwYNCAEBF4JignYjA6x+eoExgQGIGYFlgREsjnNDgUlEgTwMgkcwPogagmUEmHUmBA8DGi00EoEhcQEIBgMDBwoFMgYCDBgUBAITElMdAhIFBwocDhQcJBkMDwMSAxEBBwILEggVLAgDAgMIAwIDIwsCAxcJBwoDHQgKHBIQFAIEEx4LCAMZHywJAgQOA0MICwoDEQQDExgLFggQBAYDCS8NKAsDFA0BBgMGAgUFAQMgAxQDBScHAyEHCyYNDQQcBx0DAwUmAwICGwcCAgMCBhcGAgJvCiYNCAQIBBwdJBAFAgcxBQQvAh4EBQYRCQIWAgYEBQIEBBYCAhIIAggnGwcWGR0ZAQVdBgsJIRwKHwsGBQYWAyNzBQo+Dyk1NjwvIRsKgSgGIgEbAppIgTGCQ8FDg1iEGZtlBg8ELZZnkXmHIo9KogCFM4FnAYIOMxoIGxWDJFAZD445jjlCbAIGAQoBAQMJjwEBAQ
IronPort-Data: A9a23:GwqwCqhoxvfbrubv3oskPr7OX161vhAKZh0ujC45NGQN5FlHY01je htvX2CAPaqCNGPwf953O9jk9RkEsMfdzIRgGQA5qykzRHhjpJueD7x1DKtf0wB+jyHnZBg6h ynLQoCYdKjYdleF+lH1dOKJQUBUjclkfJKkYAL/En03FFYMpBsJ00o5wbZn29Mw2LBVPivU0 T/Mi5yHULOa82Yc3lI8s8pvfzs24ZweEBtB1rAPTagjUG32zhH5P7pDTU2FFEYUd6EPdgKMq 0kv+5nilo/R109F5tpICd8XeGVSKlLZFVDmZna7x8FOjzAazhHe3JrXO9I8N1ZSkj6Uwuxb7 /wK7Jq5VRwEE6jlzbF1vxlwS0mSPIVP9aWCKn+lvInPiUbHaHDrhf5pCSnaP6VBpb0xWjEIr 6RDbmpXBvyAr7reLLaTUvF3i8IqL+HgPZgUvTdryjSx4fMOG8yeHPqRvbe02h88uMYWFvD9Y vAkZCBKay7CYBpjOW0YXcdWcOCA3ymjLGIwREiujaYt6mbPiRN41reoNMHPP8SQSMtUjgOFo HjL9m/5CxseOfSexCaLtHW2iYfnkTnyVp5XDKWj+/hjgxiX3XZWCRIOEEahrPCyigumQd9RK lw8+ycyo+417kPDZt3mRTW5rWKK+BkGVLJ4HPA89AyXjLTd5TGVC18aQzpNZfQgs8w3THoh0 Vrht8zgAzNmsb+IT1qB7baSojOvMG4SN2BEbilsZREC6dT5vKkphwndU9UlFqOp5uAZAhn5z irPrTA5nalWi8cXka665lvAxTmro/AlUzLZ+C33AHOg9whkObKPQKXvsF7S8e1tAYOwGwzpU Gc/p+CS6+UHDJeonSOLQfkQELzB28tpIAEwknY0QMZ8r2XFF2qLONEPsGsndS+FJ+5dIWexC HI/rz+983O6AZdLUUOVS97hYyjJ5fG+fTgAahwzRoAXCqWdjCfdoElTibe4hggBanQEn6AlI ou8es2xF3scAqkP5GPoGrpHiuZ3nHFvmji7qXXHI/KPjOf2iJm9FOltDbdyRrtRAF6s+V+Mq I8Pa6NmNT0GC7akCsUozWLjBQlacSdkbXwHg8dWbeWEahF3A30sDuS5/F/SU9INokihrc+Rp ivVchYBkDLX3CSXQS3XOiELQO6+Bv5X8CNkVRHAyH71ghDPl670t/xBH3b2FJF6nNFeIQlcF KRcIpzeXK0eFVwqOV01NPHAkWCrTzzz7SrmAsZvSGFXk0JIL+ARxuLZQw==
IronPort-HdrOrdr: A9a23:yBuLH6wZcEn3s+stPFNiKrPwHb1zdoMgy1knxilNoNJuA6+lfr OV/cjzsiWE7gr5OUtQ/uxoV5PsfZqxz+8R3WBVB8bHYOCEggeVxeNZh7cKqgeIc0bDH6xmpM VdmsNFZuEYY2IbsS+32maF+xJK+qj+zEhu7t2utktQcQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.91,302,1647302400"; d="scan'208";a="2457730"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jun 2022 13:53:29 +0000
Received: from [10.147.24.42] ([10.147.24.42]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id 25FDrTZf021660; Wed, 15 Jun 2022 13:53:29 GMT
Message-ID: <36918b32-9a00-5212-1277-cf7a19826182@cisco.com>
Date: Wed, 15 Jun 2022 15:53:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
To: Robert Raszuk <robert@raszuk.net>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>, lsr <lsr@ietf.org>, draft-ppsenak-lsr-igp-ureach-prefix@ietf.org, draft-wang-lsr-prefix-unreachable@ietf.org
References: <41ba8fd6-ab16-6278-ba22-91a6a632ed33@cisco.com> <B8F7E718-28A3-4F97-A171-72774F8F1ACF@tsinghua.org.cn> <a71b7df5-4f15-a3ca-6783-3304dacd945b@cisco.com> <CAOj+MMGcgP-hH6zi_7NAkfBbQoGw0Si=55XyK_uEuA76TuGJ7w@mail.gmail.com> <c713806d-6c30-c706-850b-91e3fbcd40ba@cisco.com> <CAOj+MMHZkTJ3kKdgRxFvOzZhdQYrnp1Hn2gANmu_SmntQV5-zg@mail.gmail.com> <9abe29de-d9a2-a65d-d979-c5955e00da93@cisco.com> <CAOj+MMHoHiX+ZhTMRm9UtgupexvwfjiuCG+5EVO5+g4eJB7WGw@mail.gmail.com>
From: Peter Psenak <ppsenak@cisco.com>
In-Reply-To: <CAOj+MMHoHiX+ZhTMRm9UtgupexvwfjiuCG+5EVO5+g4eJB7WGw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.147.24.42, [10.147.24.42]
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ktoF0-0XTDyJi6-Bvppkp_XNm88>
Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jun 2022 13:54:08 -0000

On 15/06/2022 15:41, Robert Raszuk wrote:
>     Traffic will initially switch to alternate path, if any, an
>     later the native mechanism (BGP signalling, tunnel keepalive, etc),
>     will
>     take over and bring it to its final state.
> 
> 
> On one hand you are saying that UPA is useful where there is no BGP. So 
> let's talk about such a scenario.

looks to me that you are trying to steer the discussion towards the BGP 
based solution. Not something I'm interested on this thread.

> 
> Also not all tunnels have keepalives. I am talking about mGRE 
> encapsulation as an example where you simply encapsulate and have no 
> idea other than consulting RIB if the dst node is up or down.

in such case you can not use summarization at all.

thanks,
Peter


> 
> In this discussed case it will keep sending packets to remote area only 
> to drop it there ... not good.
> 
> Thx,
> R.

v2.23.0 | Report a Bug | By Email