Re: [Lsr]

Gyan Mishra <> Tue, 09 March 2021 01:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A64293A1B73; Mon, 8 Mar 2021 17:11:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Status: No, score=-2.086 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, RCVD_IN_DNSWL_BLOCKED=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 D56krCsCOR8H; Mon, 8 Mar 2021 17:11:08 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B62F3A1B71; Mon, 8 Mar 2021 17:11:08 -0800 (PST)
Received: by with SMTP id y13so4904408pfr.0; Mon, 08 Mar 2021 17:11:08 -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=7MvnjY+gdwz3ktPxI7nU5oUa3idcDGaBzicgXiovKqA=; b=aA41t0PiZrISHf9raP5vVcvCKTBPXlv5JYkwoYHd1tNfjAkiLS0bLY9yjbv89qZecM hYSX5N11cDMUZ2ghd0k7sa8dYqb8FW2SFj7VxmWZ8Dg77MDfs43UrepF1R/qWcTDqC7z DIBu/U5gvmfgBCsZp4l6BPKsPc3NdQHp6xJHtn8n8ny+A9pwQlG3/xYJ8GC6TOAseU5S f9iqUBww1wx8O5JvKzC3CDiUQ5Lw2KjKl4j/37GhKc0HFxpH+tlbg+pHc0MJc/8JS7Ei ITJcUQP0wLZX9RVjVSRJwOFSQm3MM+zV/LYaOanKarS5qq1v020FWpUxkCz0QbOyYz02 R3PA==
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=7MvnjY+gdwz3ktPxI7nU5oUa3idcDGaBzicgXiovKqA=; b=Dq3AgAOZGEay+6HpNsfY0ve2Xn27Q2ejLRgTrBRwLFkfRUqvIJsolvh/TeT4n2SWij o4JvutgDh70X82WaiKzCMNa0EikTFl6eswlG1kX068SX6dp/IShL2U57SHlK3nutEk6k bwJDFEgOJNhqDQSOtQpsUD2IZ+Zu7SICPXmW+bYnT/39rhoDP7Nk8yp0QPhCklbT9NSz M/NSbIBzyTSr7/GQ+KyokOIS1Bos+U9OHrmZo0iPI3/UpaqPjG/XvMp+qDbiIpOA1uMo 2qxVXetbZP7WXY9HLLtRRfLH6R6Q6xoI2bqlIMDXHP4Wx3KgcFgcl5FncbKKDmYFBv3/ h5Jw==
X-Gm-Message-State: AOAM530mqC5Yt8lWsEAx7az8dLzSH8y8ArF50PRY/GGY0Y7JKBO+bzij NsQ97ToTVHEFAf9+BymH2rDE+e7lzYr6PRvW7NI=
X-Google-Smtp-Source: ABdhPJycQiPUPMz2TiL/IvQWDC4coI80WYRNZprkTWIapyXgzBfwaRC3uBV+EfsoNup2WMaC1JMwP9uyzl4Pyc+/rW4=
X-Received: by 2002:a63:eb53:: with SMTP id b19mr6025129pgk.383.1615252266274; Mon, 08 Mar 2021 17:11:06 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Mon, 08 Mar 2021 20:10:55 -0500
Message-ID: <>
To: "Acee Lindem (acee)" <>
Cc: Aijun Wang <>, draft-wang-lsr-prefix-unreachable-annoucement <>, lsr <>
Content-Type: multipart/alternative; boundary="0000000000008dd32005bd1039c2"
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 01:11:11 -0000

On Mon, Mar 8, 2021 at 7:37 PM Acee Lindem (acee) <> wrote:

> Speaking as a WG member:
> Hi Gyan,
> The first question is how do you know which prefixes within the summary
> range to protect? Are these configured? Is this half-assed best-effort
> protection where you protect prefixes within the range that you’ve
> installed recently? Just how does this work? It is clearly not specified in
> the draft.
>  Gyan>  All prefixes within the summary range are protected see section 4.

   [RFC7794] and [I-D.ietf-lsr-ospf-prefix-originator
draft both define
   one sub-tlv to announce the originator information of the one prefix
   from a specified node.  This draft utilizes such TLV for both OSPF
   and ISIS to signal the negative prefix in the perspective PUA when a
   link or node goes down.

   ABR detects link or node down and floods PUA negative prefix
   advertisement along with the summary advertisement according to the
   prefix-originator specification.  The ABR or ISIS L1-L2 border node
   has the responsibility to add the prefix originator information when
   it receives the Router LSA from other routers in the same area or

When the ABR or ISIS L1-L2 border node generates the summary
   advertisement based on component prefixes, the ABR will announce one
   new summary LSA or LSP which includes the information about this down
   prefix, with the prefix originator set to NULL.  The number of PUAs
   is equivalent to the number of links down or nodes down.  The LSA or
   LSP will be propagated with standard flooding procedures.

   If the nodes in the area receive the PUA flood from all of its ABR
   routers, they will start BGP convergence process if there exist BGP
   session on this PUA prefix.  The PUA creates a forced fail over
   action to initiate immediate control plane convergence switchover to
   alternate egress PE.  Without the PUA forced convergence the down
   prefix will yield black hole routing resulting in loss of

   When only some of the ABRs can't reach the failure node/link, as that
   described in Section 3.2
the ABR can reach the PUA prefix
   should advertise one specific route to this PUA prefix.  The internal
   routers within another area can then bypass the ABRs that can't reach
   the PUA prefix, to reach the PUA prefix.

The second comment is that using the prefix-originator TLV is a terrible
> choice of encoding. Note that if there is any router in the domain that
> doesn’t support the extension, you’ll actually attract traffic towards the
> ABR blackholing it.
>  Gyan> I will work with the authors to see if their is any alternative PUA
> process to signal and detect the failure in case prefix originator TLV is
> not supported.
> Further, I think your example is a bit contrived. I’d hope that an OSPF
> area with “thousands” of summarized PE addresses wouldn’t be portioned by a
> single failure as in figure 1 in the draft and your slides. I also that the
> option of a backbone tunnel between the ABRs was removed from the draft
> since it diminished the requirement for this functionality.
>  Gyan> This is a real world Metro access edge example as the impact is
> customers that have LSP built to the down egress PE that has not failed
> over.  In this scenario their is a Primary and Backup PE per Metro edge
> which is typical for an operator.

The workaround used today is to flood all /32 next hop prefixes and not
> take advantage of summarization.  This draft makes RFC 5283 inter area FEC
> binding now viable for operators.

> Thanks,
> Acee
> *From: *Gyan Mishra <>
> *Date: *Monday, March 8, 2021 at 6:57 PM
> *To: *Acee Lindem <>, Aijun Wang <>,
> draft-wang-lsr-prefix-unreachable-annoucement <
>>, lsr <
> >
> *Subject: *
> Acee.
> Please ask the two questions you raised about the PUA draft so we can
> address your concerns.
> If anyone else has any other outstanding questions or concerns we would
> like to address as well and resolve.
> Once all questions and  concerns are satisfied we would like to ask for WG
> adoption.
> Kind Regards
> Gyan
> --
> [image: Image removed by sender.] <>
> *Gyan Mishra*
> *Network Solutions Architect *
> *M 301 502-1347 13101 Columbia Pike
> <>
> *Silver Spring, MD


*Gyan Mishra*

*Network Solutions A**rchitect *

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