Re: [Lsr] Prefix Unreachable Announcement Use Cases
Gyan Mishra <hayabusagsm@gmail.com> Tue, 17 November 2020 14:28 UTC
Return-Path: <hayabusagsm@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 576033A137F for <lsr@ietfa.amsl.com>; Tue, 17 Nov 2020 06:28:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 Ccx8vU9H1vFg for <lsr@ietfa.amsl.com>; Tue, 17 Nov 2020 06:28:56 -0800 (PST)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 74EFC3A1393 for <lsr@ietf.org>; Tue, 17 Nov 2020 06:28:56 -0800 (PST)
Received: by mail-pl1-x632.google.com with SMTP id t18so10324511plo.0 for <lsr@ietf.org>; Tue, 17 Nov 2020 06:28:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rbBs73zR+QUtqqUOXI69uEoQArffgw1X2HuwDnAx2Nw=; b=k2/vYfNlyGRUbLdhWxo5prNr9Cilf3ixbsIqWUS7jxb9gNQqiWokGJ9ElzV4VwJxGX WZnXDXd33SuXKXtRplon8Bt5tE4okt7xajehKZoXFVNS6T14pRx/3q+/9h7FA41h2UXl RGB+ZF532i+fGL30RuZA960sBwVTkvFe/WjwfE2BJtO3vbSf510wQSpwhXsF6j1lkCrh J1dTXSp6fDoOXvjPUl9bw2WNrC9Gh3Aq9cZVPq+JLPxdbs3aX+aE5X97yP8cSTdzPFU3 Nno646ygvbnFG6DlaWOooiEjZd4BjHxpqUg/GyD43vfjc+CgCvSK9k5SJHIqq10RNNXZ u8Kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rbBs73zR+QUtqqUOXI69uEoQArffgw1X2HuwDnAx2Nw=; b=t9ad8wvY2YqvITMNHIFaM94nUJBzrpNs+zjPlqALuHzLzyIufJ2/m5i3qK9D9i37ZO ZvUI4US0HXubDwKc6x10PmWuEBqnCiwskPb+fdSy98rzsfGz7FVi6B/TDJ7R40EBDBZU jz9aKG8jUxiWdMLkrM80YF73PEfFusry5SZMTKG9teYv3NRzVag3DhJ/xIJ6xuJGLCR4 KaZHkhyy2BOEcZof1GP9co8Zs3AsiHv6QB/KApEoWK7OC6R3Di/6VlAcPdm2jA8/ZlXf tDOmW3bpoC3XFuqMhxilGAoFfkqVse03x9t8QHSCS6SOBWvjR1/a2EmaIA2CjOjWK8Sp h+WQ==
X-Gm-Message-State: AOAM532QVvOAHKeu/HEDAp5VsHnR4jz5bACl2lLhllLZ4Z8LtWcJdYCe TWJTBnqI/QXe6o/EariBOCXu8l18lBHcQaT0Re4=
X-Google-Smtp-Source: ABdhPJzG9J9xR/wxoyxgSJSaVUDR7uwxtsMYk6kMRBWLRFd3eb9ppjeHKpiPC62kaCIX6lYJgsoD8ybclh5XFhTVS5k=
X-Received: by 2002:a17:902:7c01:b029:d8:ee2a:ce88 with SMTP id x1-20020a1709027c01b02900d8ee2ace88mr8637178pll.22.1605623335721; Tue, 17 Nov 2020 06:28:55 -0800 (PST)
MIME-Version: 1.0
References: <CAOj+MMH7zRaXNJTRC0ua7ohasUpo0MmeqgzcU9BdpcD7wD+Yrg@mail.gmail.com> <D477846E-1086-46A8-B2D6-E552623E2643@gmail.com> <016b01d6bca9$cf908c20$6eb1a460$@tsinghua.org.cn> <CAOj+MMEKbBU1mymU2RzWzwi6Se8ZwQ9OsCBn4NUiX3YAceLdoQ@mail.gmail.com> <CABNhwV1yS1KdPe0hYGOUhDBpqbNqZCaO=xNEr_LaRg35b=f55g@mail.gmail.com> <CAOj+MMGnRkYrTcC45QEy+F5HNCoFn75r=1gn-+OT89Q53D_pYA@mail.gmail.com> <CABNhwV1pK5JX5sDcPyRKuR67eAkAq-q3wRmYqbsfCwOj0wWjSw@mail.gmail.com>
In-Reply-To: <CABNhwV1pK5JX5sDcPyRKuR67eAkAq-q3wRmYqbsfCwOj0wWjSw@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Tue, 17 Nov 2020 09:28:44 -0500
Message-ID: <CABNhwV1o6PHhmYawMs8iZm-Zvwo2yAFyPp+_jkrEeF50LcWh-A@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, Aijun Wang <wangaijun@tsinghua.org.cn>, Jeff Tantsura <jefftant.ietf@gmail.com>, lsr <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000919dd705b44e5084"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/WUK0NCTcqYO8cGRDYjSsEMaW148>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases
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, 17 Nov 2020 14:28:58 -0000
On Tue, Nov 17, 2020 at 4:01 AM Gyan Mishra <hayabusagsm@gmail.com> wrote: > > > On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk <robert@raszuk.net> wrote: > >> >> >> Robert, I believe the original intention was related to having the >>> data plane converge quickly when summarization is used and flip so traffic >>> converges from the Active ABR to the Backup ABR. >>> >> >> I do not buy this use case. Flooding within the area is fast such that >> both ABRs will get the same info. As mentioned before there is no practical >> use of PUA for making any routing or fwd decision on which ABR to use. If >> your ABRs are not connected with min redundancy this draft is a worst patch >> ever to work around such a design. >> > > Gyan> Agreed. The point of PUA in ABR use case is the ability to track > the component prefixes and in case where component is down and traffic is > still forwarded to the ABR and dropped. The other more important use case > is when links are down within the area and the area is partitioned and so > one ABR has all component prefixes however other ABR is missing half the > component prefixes. So since the ABR will by default advertise the summary > as long as their is one component UP the summary is still advertised. So > this use case is severely impacting as now you have an ECMP path to the > other area for the summary via the two ABRs and you drop half your > traffic. So now with PUA the problem is fixed and the PUA is sent and now > traffic is only sent to the ABR that has the component prefixes. > >> >> Please present us a picture indicating before and after ABRs behaviour. >> > > Gyan> will do > >> >> However PUA can be used in the absence of area segmentation within a >>> single area when a link or node fails to converge the data plane quickly by >>> sending PUA for the backup path so the active path. >>> >> >> If there is no area segmentation then there is no summaries. So what are >> we missing in the first place ? >> > > Gyan> Sorry I am stating that PUA feature can also be used intra area > where if a link or node goes down to improve data plane convergence. > >> >> >> >>> With the IGP tuned with BFD fast detection on ISIS or OSPF links and LFA >>> & RLFA for MPLS or TI-LFA for SR local protection - with those tweaks the >>> convergence is well into sub second. So for Intra area convergence with >>> all the optimizations mentioned I am not sure how much faster the data >>> plane will converge with PUA. >>> >> >> Even without any of the above listed chain of acronymous things will >> generally work well intra-area without PUAs. >> > > Gyan> Agreed which is why I mentioned the BGP next hop self use case > if I could figure out how PUA could help there that would be a major > benefit of PUA. > Gyan>. We could use Aijun’s passive interface new top level TLV to link the next hop rewrite loopback to the PE-CE links all being set to passive. So if any PE-CE link goes down a PUA is sent and the next hop converges PIC core PE-CE link which is now associated with the Loopback. This would be a major benefit of PUA for PIC core convergence when next-hop-self is used which applies to MPLS and SR and IP based core. https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-attribute/ So the two main critical use cases where this solution solves a problem is partitioned area scenario and nest hop convergence when next-hop-self is used scenario. I will update the presentation deck and share. >> Thx, >> R. >> >> >> -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > > > *M 301 502-134713101 Columbia Pike *Silver Spring, MD > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
- [Lsr] Prefix Unreachable Announcement Use Cases Acee Lindem (acee)
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… 王爱俊
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Aijun Wang
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Jeff Tantsura
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Jeff Tantsura
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Aijun Wang
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Acee Lindem (acee)
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Jeff Tantsura
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Aijun Wang
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… tony.li
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Acee Lindem (acee)
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Huzhibo
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Jeff Tantsura
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Aijun Wang
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Acee Lindem (acee)
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Aijun Wang
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Tony Przygienda
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Aijun Wang
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Aijun Wang
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Tony Przygienda
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Tony Przygienda