Re: [Lsr]

Gyan Mishra <> Tue, 09 March 2021 04:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3FAE3A0E94; Mon, 8 Mar 2021 20:23:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.087
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RkRJMvPlqdzg; Mon, 8 Mar 2021 20:23:03 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C959D3A0E93; Mon, 8 Mar 2021 20:23:03 -0800 (PST)
Received: by with SMTP id 30so1370363ple.4; Mon, 08 Mar 2021 20:23:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zMlyvhZQg5pRW3P8v+8AYvjYFty4pCTkSkEEQEdPZWQ=; b=PNFJbuqut9BWGkzfEC7baLRDKlo6t9IK9JXl+llltSpW7+bfVzQ8xUTYc9wxhupAHk JNJEyhTYqq08xY7irM3xIw7CKHWWray6bceMZyjvKrNUtEBi1HyBEFkT8n41YhzH8/um zESRYvnP0iK6Yh/VnmP5ZU0iHcbuTFhAa6Kf+yCuljhorTMAgJtcNi8lB3GRQohxl/7k ggSzsr63/9GK+Pw7CgMt8swZJ2RPnVEhwr12OfcH2+L8lL+LOPst77vvlNFWQeaOLL+G MM0xqOXAT7XE6+admQcXAwOzzkDURLkr5nZSjTUqxUotnKF+8oiLk4o1jZM2oeI9Y7li 9gpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zMlyvhZQg5pRW3P8v+8AYvjYFty4pCTkSkEEQEdPZWQ=; b=HcnUQ7+vvVNb76hddqfuVjTcAMnwK1H9XSrDGU9v5NME7aTqISJtLD7I83zNnjS8qH Upaka1lifcZ+kkwpV+o0hT+ajFRMQCKL08AnLjIru2YB/mWcFyn2hXcL2ReRGsG9RgHX 4/J1DcDcA3M0lq6j9OUwrSl1/fhTHy8543EnW2bcDTYqOptAjkD7xWNQk3TYVw0GSb3c uSFAl2+dYQ2Ufu8U/RDh92EfM+wifx6TENB3DpvaIbe3z4PG5K01gJFvb0MrqqN9dBHI abuTVjkOUDpAKpZtpSdfEVlic60L66/MkGk09IkENDbPy+0QvSIMSsRuH0wb1X6rZPbQ i75w==
X-Gm-Message-State: AOAM531cDsR3rRh3NN8YCzn1Tdbsnowyfqt+k8PhtQFRG3c4YitWq+zu 99RegTVFCGL0Ie4Z04yoaPxayNvDbVRUvaWRrSlBwPnbpvM=
X-Google-Smtp-Source: ABdhPJwdBOFGx8JXuZ/EBnrDAVQXFB6WAItK9RsqEe+ZrqMELAO+uiBjyHJevnM76hDIJb2/dCCFtc0c/6E/xpNOfZA=
X-Received: by 2002:a17:902:fe09:b029:e4:951e:2d2e with SMTP id g9-20020a170902fe09b02900e4951e2d2emr24408067plj.22.1615263782253; Mon, 08 Mar 2021 20:23:02 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <018801d71499$9890feb0$c9b2fc10$>
In-Reply-To: <018801d71499$9890feb0$c9b2fc10$>
From: Gyan Mishra <>
Date: Mon, 08 Mar 2021 23:22:51 -0500
Message-ID: <>
To: Aijun Wang <>
Cc: "Acee Lindem (acee)" <>, Aijun Wang <>, Tony Li <>, draft-wang-lsr-prefix-unreachable-annoucement <>, lsr <>
Content-Type: multipart/alternative; boundary="000000000000f5b8f705bd12e7ab"
Archived-At: <>
Subject: Re: [Lsr]
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Mar 2021 04:23:06 -0000

Hi Tony

Thank your for your comments.

Responses in-line

Kind Regards

On Mon, Mar 8, 2021 at 11:06 PM Aijun Wang <>

> Hi, Tony:
> -----Original Message-----
> From: <> On Behalf Of Tony Li
> Sent: Tuesday, March 9, 2021 11:12 AM
> To: Aijun Wang <>
> Cc: lsr <>; draft-wang-lsr-prefix-unreachable-annoucement <
>>; Acee Lindem
> (acee) <>; Aijun Wang <>; Gyan
> Mishra <>
> Subject: Re: [Lsr]
> Hi Aijun,
> > [WAJ] We just want to avoid such silent discard behavior, especially for
> the scenario that there is BGP session run on such failure prefix.
> 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.

    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.

> > 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?

    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.

> >>> For scenarios 2, because the specified prefixes can be accessed via
> another ABR, then we can let this ABR to advertise the details prefixes
> information for the specified address, which behavior is similar with RIFT,
> as also mentioned in the presentation materials.
> >>
> >>
> >> Agreed.
> >
> > [WAJ] Even for this scenario, the advertisement of the detail prefixes
> is trigger also via the PUA message from other ABR.
> 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.

      Gyan>As I mentioned advertising flooding of the longer prefix defeats
the purpose of summarization. In order to do what you are stating you have
to remove the summarization and go back to domain wide flooding 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.  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.

> Tony
> _______________________________________________
> Lsr mailing list
> --


*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD