Hi Zhibo,

> However, if there is a summary or default route in the area, FIB Miss
cannot be triggered.

If PUA is a /dev/null route this is not a FIB miss. It's a FIB hit.

Thx,
R.

On Wed, Nov 18, 2020 at 3:36 AM Huzhibo <huzh...@huawei.com> wrote:

> Hi Tony:
>
>
>
> In fact, this protection use case protects the SRv6 mid-point.
> https://datatracker.ietf.org/doc/draft-chen-rtgwg-srv6-midpoint-protection/.
> When the SRv6 mid-point fails, the PLR node can perform the next SID
> operation, which is triggered by FIB miss. However, if there is a summary
> or default route in the area, FIB Miss cannot be triggered.
>
>
>
> Thanks
>
>
>
> Zhibo
>
>
>
> *From:* Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *tony...@tony.li
> *Sent:* Tuesday, November 17, 2020 2:31 PM
> *To:* Aijun Wang <wangai...@tsinghua.org.cn>
> *Cc:* lsr <lsr@ietf.org>; Jeff Tantsura <jefftant.i...@gmail.com>; Robert
> Raszuk <rob...@raszuk.net>; Acee Lindem (acee) <acee=
> 40cisco....@dmarc.ietf.org>
> *Subject:* Re: [Lsr] Prefix Unreachable Announcement Use Cases
>
>
>
>
>
> And how would that help connectivity restoration ?
>
> *[WAJ] This action will trigger the path protection procedures, which will
> divert the traffic to other backup path.*
>
>
>
>
>
> This seems to be making some major assumptions about how path protection
> features operate. Those assumptions need to be
>
> very explicitly called out.
>
>
>
> The path protection features that I’m familiar with are triggered by
> topological changes along the existing operable path. A PUA
>
> does not provide that.  Rather, it’s something of a temporary signal
> saying ’this broke’. Without more specifics about the failure, it’s
> difficult to
>
> understand exactly what path protection should make of this.  If a prefix
> is unreachable, the obvious implication is that the associated link has
>
> failed.  Path protection in a remote area is highly unlikely to have the
> topological details necessary to find an alternate path to that prefix.
>
>
>
> Tony
>
>
>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to