Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

Ketan Talaulikar <ketant.ietf@gmail.com> Wed, 20 March 2024 15:17 UTC

Return-Path: <ketant.ietf@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 E3509C151990; Wed, 20 Mar 2024 08:17:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7e6FF24uhN5; Wed, 20 Mar 2024 08:17:52 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087CAC15198B; Wed, 20 Mar 2024 08:17:51 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5688eaf1165so10001908a12.1; Wed, 20 Mar 2024 08:17:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710947870; x=1711552670; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MwOGs+upAkDPUuq74nNW8obMdzrWIkujZg+0stRelmY=; b=gmduXeqSjgL3mVGK5P5CjCliI68zlrdz/K9K8USPRkcOMBO25e8OXMTcd44MosEv55 Dpt/eDs6dffvZmsdDI+0+vxVh/XVeHzRx7JO/ue8+XENfGCoB0azjoSLIb+X96bqlJb4 B28/3ENeBftM6TGJVS5ftYAti7w5ZuwjAgqIPST0T/f4O4l7G7kXvMpp3LqtVM2NOAnk GwHZcET8B2XLgUkuqR/s+YPXgWV5S368FiW9zw0eN7QefEOZJLUMrF9zrtD3QHCEW+2i 2LoKyBEcuJxBYR4IU1nnw6Zro+2vGj6jlfP6uBDWuv0yjzGEG3NVG25b6OpuQdM0ZWwE 6zoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710947870; x=1711552670; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MwOGs+upAkDPUuq74nNW8obMdzrWIkujZg+0stRelmY=; b=W3oU7l7hx0+Mkgrs7A1ltrQTqrHl3aQt+Uc4QbZMNceAdtj8yr2X7pgesDtSPxHhCT f8L8yg22sJys+QGGRRhYxekbWGpxR70XNbIBC/Lu9G6tSDotmplXvWa8lOZQmBfIE1Ef WMgI9OnfwApHt0H2lXNGALvb6F42o83E7HsHfC9B3GhtRhS8Ff62MspKpCjkWeXLyjy0 PQg7nmgppDinbw+Cuk1EqL2MarQxFLiATSrAWseiw2bS3dEACpvP7k5xM3EYoRSIPzgQ moIbbWKFE5Kwg524l/5zgrdNUBWmTMDCJSOKqOxWKreiu0w0ejdJAavGE7w20UfvlltJ ihXQ==
X-Forwarded-Encrypted: i=1; AJvYcCVkT6hOp1DwE5znW5awrptutM/EV2QRdXanGbJol6UZiGUsBtBmJDRFu7jY6ellICQebNb1sRUwMOiFr1zTomBKtRKNk4rL19Y2SDusuO+vSjB3BsSHWmDU+mxx1wV3l6v0Lg==
X-Gm-Message-State: AOJu0YyhnwKVs8r13ZEpNym0+NNM1vP7fTu5meTZaCFdWUzZ9IwXwDhx OW0hSTaZmLUacs+99EpEWfQGIK/rl3hM3frJgovDOkePb3S0Z0fYPl7YQko15b101Z8QfMBLE/4 6vDbBckhtDK/XxAAIW1UFlESggMQ=
X-Google-Smtp-Source: AGHT+IH225H+fkiuxxyhpERtXv9qO4e2OdfOkgy91b3PFV5r13HV7STfNRR/P3l7E8iIC64VEnjjywbXeTR3juX+mhQ=
X-Received: by 2002:a17:906:c78b:b0:a46:e0d2:393a with SMTP id cw11-20020a170906c78b00b00a46e0d2393amr3997192ejb.60.1710947870166; Wed, 20 Mar 2024 08:17:50 -0700 (PDT)
MIME-Version: 1.0
References: <F425E082-D008-4565-98AE-98593BF1F391@gmail.com> <fc9a254a5ff8405e88e55a9b61a4140c@huawei.com> <F94C2512-9D9F-4862-AAE7-FE628DC6E3B7@gmail.com>
In-Reply-To: <F94C2512-9D9F-4862-AAE7-FE628DC6E3B7@gmail.com>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Wed, 20 Mar 2024 20:47:38 +0530
Message-ID: <CAH6gdPz20GVQ_iP+GYTfmsWRxm7cwFrf_GZ9vxhp1Rv6pZrfJQ@mail.gmail.com>
To: Acee Lindem <acee.ietf@gmail.com>
Cc: "Dongjie (Jimmy)" <jie.dong@huawei.com>, lsr <lsr@ietf.org>, "draft-chen-lsr-anycast-flag@ietf.org" <draft-chen-lsr-anycast-flag@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000007d82f0614191801"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Zv7Wy6o-vpHcmSIw902wZkBsLjY>
Subject: Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 20 Mar 2024 15:17:56 -0000

Hi Acee/Jie,

The most common users of the anycast property of a prefix are external
controllers/PCE that perform path computation exercises. As an example,
knowing the anycast prefix of a pair of redundant ABRs allows that anycast
prefix SID to be in a SRTE path across the ABRs with protection against one
of those ABR nodes going down or getting disconnected. There are other use
cases. An example of local use on the router by IGPs is to avoid picking
anycast SIDs in the repair segment-list prepared for TI-LFA protection -
this is because it could cause an undesirable path that may not be aligned
during the FRR window and/or post-convergence.

That said, since ISIS (RFC9352) and OSPFv3 (RFC9513) didn't have the burden
of this justification of an use-case, I hope the same burden would not fall
on this OSPFv2 document simply because it only has this one specific
extension.

Thanks,
Ketan


On Wed, Mar 20, 2024 at 8:16 PM Acee Lindem <acee.ietf@gmail.com> wrote:

> Hi Jie,
>
> I asked this when the flag was added to IS-IS and then to OSPFv3. I agree
> it would be good to know why knowing a prefix is an Anycast address is
> "useful" when the whole point is that you use the closest one (or some
> other criteria).
>
> Thanks,
> Acee
>
> > On Mar 20, 2024, at 9:09 AM, Dongjie (Jimmy) <jie.dong@huawei.com>
> wrote:
> >
> > Hi authors,
> >
> > I just read this document. Maybe I didn't follow the previous
> discussion, but it seems in the current version it does not describe how
> this newly defined flag would be used by the receiving IGP nodes?
> >
> > Best regards,
> > Jie
> >
> > -----Original Message-----
> > From: Lsr <lsr-bounces@ietf.org> On Behalf Of Acee Lindem
> > Sent: Wednesday, March 20, 2024 4:43 AM
> > To: lsr <lsr@ietf.org>
> > Cc: draft-chen-lsr-anycast-flag@ietf.org
> > Subject: [Lsr] Working Group Adoption Poll for "Updates to Anycast
> Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
> >
> >
> > This starts the Working Group adoption call for
> draft-chen-lsr-anycast-flag. This is a simple OSPFv2 maintenance draft
> adding an Anycast flag for IPv4 prefixes to align with IS-IS and OSPFv3.
> >
> > Please send your support or objection to this list before April 6th,
> 2024.
> >
> > Thanks,
> > Acee
> >
> >
> > _______________________________________________
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>
>