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

Tony Li <tony.li@tony.li> Tue, 09 March 2021 04:32 UTC

Return-Path: <tony1athome@gmail.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 624F23A0FAF; Mon, 8 Mar 2021 20:32:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Z4xIFw48p22g; Mon, 8 Mar 2021 20:32:25 -0800 (PST)
Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F5723A0FC7; Mon, 8 Mar 2021 20:32:25 -0800 (PST)
Received: by mail-pj1-x1034.google.com with SMTP id i14so194301pjz.4; Mon, 08 Mar 2021 20:32:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=V3mDvq5bsLrck/n8o/Uf8CrIR5sTDerRun5FdJN3B8o=; b=aAlJuDxFHMqKYwzVkrJDFbB2AMRG0spuKUpwVUkVOvNs3B3ePuqbC7TBZxPm1WOYfj aSdGsjIg0/rOr6R9PI6GnMYYMDBY5Fkrsp1ZrN8ymiTGD1ePxArHd30yVrznb9fM24by xVVYwaGT5Fmsb/o6wbXwph1cbrTnyAYX35KVAVF4i4OobLlBMHOqd2LiBxXLoos4wnVn CSGZw4fVSzsbnOZIsZEB6WLkTmoW4K+hwj5U8sastUhoH6jhGijcplxGadpF3Ond0X1y GlbYxnK93X2gG7/1qefFy9iQfm9cwwVCNqBAZzazApJRF+6LA26fa+46s2FmNwlp3ajL bi6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=V3mDvq5bsLrck/n8o/Uf8CrIR5sTDerRun5FdJN3B8o=; b=iiAUDF/9GDonmClVA4+rRhzkCMBd78wFwrH5p9c8Jm2YpDCNv6noedTeJX8mt6SGBR WQC6hx2Wm9x4WtRHOCpR60DvNZu9f2iFrQK7V1iWVsk3nEEwxfbWN4Ys5TGd7bqjsYrh fYtVMj3XwMZxa5gD2+Y2AJJiQ/Q4pvnunJ++D6P0b+wuv3dd8q52kOamWEeVmedTSb3u dNvePENAEX9cjudWV4qQQem3O0hau20jCljzZK4Fz0sgjw96MzRu+IShoZ7uU9JSaQh8 qkv1hhH6NNb9Z1cyc5dj3ouUqWq13z6KoyRrJR8cpVOII89EOq98Pbrky01YZXtXMdMq 815A==
X-Gm-Message-State: AOAM533pDW+NZjb6mrhmCIUv7W44dfVcfm58PdkvIjJnu3A3zegJYnOG SWyik8UKlqmYGGmSLscFZPG8UHHlHIIMrw==
X-Google-Smtp-Source: ABdhPJyoKd+OqPMo0vVvsNBEJyFc3B8b9y1cKXXMUNO83HnaSacnlRJV4eAh9iOxx02Mg9GyF59DAg==
X-Received: by 2002:a17:902:74c4:b029:e4:9e16:18d9 with SMTP id f4-20020a17090274c4b02900e49e1618d9mr2091151plt.21.1615264343683; Mon, 08 Mar 2021 20:32:23 -0800 (PST)
Received: from [192.168.4.41] (c-67-169-103-239.hsd1.ca.comcast.net. [67.169.103.239]) by smtp.gmail.com with ESMTPSA id b22sm12462028pff.173.2021.03.08.20.32.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Mar 2021 20:32:23 -0800 (PST)
Sender: Tony Li <tony1athome@gmail.com>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
From: Tony Li <tony.li@tony.li>
In-Reply-To: <018801d71499$9890feb0$c9b2fc10$@tsinghua.org.cn>
Date: Mon, 8 Mar 2021 20:32:21 -0800
Cc: Aijun Wang <wangaj3@chinatelecom.cn>, lsr <lsr@ietf.org>, draft-wang-lsr-prefix-unreachable-annoucement <draft-wang-lsr-prefix-unreachable-annoucement@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>, Gyan Mishra <hayabusagsm@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EB1B201E-91CD-44BA-A68A-7DD7C7FA9464@tony.li>
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>
To: Aijun Wang <wangaijun@tsinghua.org.cn>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/PlX8lzC5aAOd4c262sqQZiTHIRQ>
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: Tue, 09 Mar 2021 04:32:28 -0000

Hi Aijun,

> Stuffing things in the IGP seems like a poor way of determining that there’s a BGP failure.  Wouldn’t BFD be a more appropriate way of determining the loss of connectivity?  Or aggressive BGP keepalive timers?
> [WAJ] For BFD, you need to configure between each pair of them to track the connectivity.  For BGP keeplive times, the duration is too long.


You have to configure BGP on both sides too.

Most implementations do allow you to change the timers.


>> The other side of BGP peer can quickly remove the BGP session when it receives such PUA message which tell it the other peer is down now. Other BGP peer protection procedures can then take effects on.
>> The immediate notification of the failure prefix can certainly accelerate the switchover of BGP control plane and also the service traffic that such BGP session carries.
> 
> 
> The IGP is a very poor way of delivering service liveness information.
> [WAJ] why? 


Because it’s not a service (un)availability protocol. It’s a reachability and path computation function.  That is it’s role in the architecture.  Asking it to do something else is a violation of the architecture.

Routing protocols are not transport protocols. Or dump trucks. Or service advertisement protocols.


> That seems 100% unnecessary as the longer prefix will attract the traffic in the way that you want.
> [WAJ] If the ABR advertises such detail prefix, it will certainly attract the traffic. But here the PUA message is just to trigger the ABR to advertise such detail prefix, or else, such ABR will still advertise the summary address.


You don’t need the PUA message. The ABR can see the loss of topology and can realize that it’s the best path to the prefix and can then advertise the explicit longer prefix in addition to the normal summary.

Tony