Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
Tony Przygienda <tonysietf@gmail.com> Wed, 20 March 2024 16:44 UTC
Return-Path: <tonysietf@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 1BB1AC180B49; Wed, 20 Mar 2024 09:44:45 -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 bNwW-eMGrOFk; Wed, 20 Mar 2024 09:44:43 -0700 (PDT)
Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 9384BC180B69; Wed, 20 Mar 2024 09:44:43 -0700 (PDT)
Received: by mail-vs1-xe36.google.com with SMTP id ada2fe7eead31-47651248841so2419751137.2; Wed, 20 Mar 2024 09:44:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710953082; x=1711557882; 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=tJ+gV+3GFGGtCTQmsAug2GkEaIRHIdlhQRXX996I1Pk=; b=Mlz3OMmVh/beyuirxgsUpF7Yo+r84qHlJzQpW157xXAe50x/na54zuXimmhPdb9jj/ PgVCgVNkefyDxOzcVe6j9jgSjpmXt5I7CTCxgMeYM4Lk/uL6NGgyfryEbyck5te88k48 3TkFtIx8tn9s4PCbSPr0cmOF5/AsFmGlGaCzoN5iqt7q9ExVIAfBdgF/1ZJ8mS/bNVPp 5XKjBgmNwd00k9MeECmBOTY6NF2jwpjic4MDKkH5ECsScA9qhJPr+F+m0N6OiiePb7id lZHuCZlwbHAkMkRyGIAlxy851C5g2134jyDukRuQ3UA5QgavlzrIPh1+pn8EPWjBJrd3 R00w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710953082; x=1711557882; 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=tJ+gV+3GFGGtCTQmsAug2GkEaIRHIdlhQRXX996I1Pk=; b=Mo1TfVusLX60QiQOiHz7QYU2XAE/n27zCgqeCyLiypwYCSfYbO1L9r629M6jMBNjhD 1L4rbcNFS/r3AxQEQ6xqu5GGGAim/B2FTpB0LaYEWs2sZm13yQvA6BzH36Yga84G/F1M ibywOCbMyh1QtRyFBKjBrT/jTsJHENYr3MofRQ+78R6iKpLWeqfnpbWevWkzsENflqL9 EtKpkcEzzPRB3W7wmZuGuo6JBzXeN6NraNCD7lfKzNqqxFlpMWDhX3OGuadSpkEjXXs1 08xkcn1UajpTBMgRRn//0KwRR6jyP0HKPNTa1VaKr6eKcNLNaA9mqrw/D49orLbXNPd0 dnvQ==
X-Forwarded-Encrypted: i=1; AJvYcCWVEh7EVj0DMtE9WcH6Up4oZMJorYKN4mhnXb9SUA853pbX1o1YqeVtGVv9LCy+FQjSICX/YRXehnU4LXmSRSsFgtsvZp9goR+qYk8NFBQmhuQpEmshCJurjNr3gXT679kR4g==
X-Gm-Message-State: AOJu0YwFtezZr1Ax7iXBOkWQ4vDvoo1dEYtdAHehmtwFUKM8uAzy9+UW adW5I8yPsgIsvgBQLJyCPghZfHBinAmXyeKtklu3eXPmv0lp7lM6Q/lDeq5UpmI1WGXm+67UmYJ zdIkG2KEwNIJqj2R4Juo40v3RSbo=
X-Google-Smtp-Source: AGHT+IHua7TGnm2Us5lm2n10bXJFTUBIpA6aRDKBqWnBy4GCdUQc5vYNcWpukl0eZrN/C+JEVs8l6Q1wsge7YnJhRrk=
X-Received: by 2002:a67:e3c9:0:b0:472:eb0a:b70b with SMTP id k9-20020a67e3c9000000b00472eb0ab70bmr14306554vsm.12.1710953081910; Wed, 20 Mar 2024 09:44:41 -0700 (PDT)
MIME-Version: 1.0
References: <F425E082-D008-4565-98AE-98593BF1F391@gmail.com> <fc9a254a5ff8405e88e55a9b61a4140c@huawei.com> <F94C2512-9D9F-4862-AAE7-FE628DC6E3B7@gmail.com> <CAH6gdPz20GVQ_iP+GYTfmsWRxm7cwFrf_GZ9vxhp1Rv6pZrfJQ@mail.gmail.com> <B8FC6DD1-4380-4960-981F-0E7A2BFA1EDE@gmail.com> <CAH6gdPzC_wd532r=HK=WPQte-ohrJJ+oXyoUiQJrrs_PVS0mEQ@mail.gmail.com> <97A76AB5-CAAF-4650-A317-57835087426A@gmail.com>
In-Reply-To: <97A76AB5-CAAF-4650-A317-57835087426A@gmail.com>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Wed, 20 Mar 2024 17:44:05 +0100
Message-ID: <CA+wi2hNaEb-JegiG7vPp8kByJfWKcPqXAj_vVaw151AnZOQcKw@mail.gmail.com>
To: Acee Lindem <acee.ietf@gmail.com>
Cc: Ketan Talaulikar <ketant.ietf@gmail.com>, "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="000000000000acc06806141a4e75"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/OXf7EU9mMzIFe2PMNBAhx-svcWk>
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 16:44:45 -0000
I think the draft is somewhat superfluous and worse, can generate completely unclear semantics 1) First, seeing the justification I doubt we need that flag. if the only need is for the SR controller to know it's anycast since it computes some paths this can be done by configuring the prefix on the controller itself. It's all centralized anyway. 2) OSPF today due to SPF limitations has a "baked-in weird anycast" since if prefixes are ECMP (from pont of view of a source) they become anycast, otherwise they ain't. I think the anycast SID suffers from same limi8ation and is hence not a "real anycast" (if _real anycast_ means something that independent of metrics balances on the prefix). Hence this draft saying "it's anycast" has completely unclear semantics to me, worse, possibly broken ones. What do I do as a router when this flag is not around but two instances of the prefix are ECMP to me? What do I do on another router when those two instances have anycast but they are not ECMP? What will happen if the ECMP is lost due to ABR re-advertising where the "flag must be preserved" . 3) There is one good use case from my experience and this is to differentiate between a prefix moving between routers (mobility) and real anycast. That needs however far more stuff in terms of timestamping the prefix. pascal wrote and added that very carefully to rift if there is desire here to add proper anycast semantics support to the protocol. So I'm not in favor in adopting this unless the semantic is clearly written out for this flag and the according procedures specified (mobility? behavior on lack/presence of flag of normal routers etc). Saying " It is useful for other routers to know that the advertisement is for an anycast identifier. " is not a use case or justification for adding this. if this is "anycast in case of SR computed paths that are not ECMP" then the draft needs to say so and call it "SR anycast" or some such stuff. If it is something else I'd like to understand the semantics of this flag before this is adopted. -- tony On Wed, Mar 20, 2024 at 5:10 PM Acee Lindem <acee.ietf@gmail.com> wrote: > Hi Ketan, > > On Mar 20, 2024, at 12:07, Ketan Talaulikar <ketant.ietf@gmail.com> wrote: > > Sure, Acee. We can take that on :-) > > I hope it is ok that this is done post adoption? > > > Yup. I realize this is a simple draft to fill an IGP gap but I did ask the > question below. Hopefully, we can get to WG last call quickly. > > Thanks, > Acee > > > > > Thanks, > Ketan > > > On Wed, Mar 20, 2024 at 9:35 PM Acee Lindem <acee.ietf@gmail.com> wrote: > >> >> >> > On Mar 20, 2024, at 11:17 AM, Ketan Talaulikar <ketant.ietf@gmail.com> >> wrote: >> > >> > 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. >> >> But they also weren't added in a draft specifically devoted to the >> Anycast flag. It would be good to list the examples above as potential use >> cases. >> >> >> Thanks, >> Acee >> >> >> >> > >> > 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 >> > >> >> > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr >
- [Lsr] Working Group Adoption Poll for "Updates to… Acee Lindem
- Re: [Lsr] Working Group Adoption Poll for "Update… Qiuyuanxiang
- [Lsr] 答复: Working Group Adoption Poll for "Update… zhao.detao
- Re: [Lsr] Working Group Adoption Poll for "Update… Zehua.Hu@foxmail.com
- Re: [Lsr] Working Group Adoption Poll for "Update… Zehua.Hu@foxmail.com
- Re: [Lsr] Working Group Adoption Poll for "Update… 谭振林
- Re: [Lsr] Working Group Adoption Poll for "Update… Dongjie (Jimmy)
- Re: [Lsr] Working Group Adoption Poll for "Update… Acee Lindem
- Re: [Lsr] Working Group Adoption Poll for "Update… Ketan Talaulikar
- Re: [Lsr] Working Group Adoption Poll for "Update… Acee Lindem
- Re: [Lsr] Working Group Adoption Poll for "Update… Ketan Talaulikar
- Re: [Lsr] Working Group Adoption Poll for "Update… Acee Lindem
- Re: [Lsr] Working Group Adoption Poll for "Update… Tony Przygienda
- Re: [Lsr] Working Group Adoption Poll for "Update… Peter Psenak
- Re: [Lsr] Working Group Adoption Poll for "Update… Tony Przygienda
- Re: [Lsr] Working Group Adoption Poll for "Update… Dongjie (Jimmy)
- Re: [Lsr] Working Group Adoption Poll for "Update… Peter Psenak
- Re: [Lsr] Working Group Adoption Poll for "Update… bruno.decraene
- Re: [Lsr] Working Group Adoption Poll for "Update… Ketan Talaulikar
- Re: [Lsr] Working Group Adoption Poll for "Update… bruno.decraene
- Re: [Lsr] Working Group Adoption Poll for "Update… Tony Przygienda
- Re: [Lsr] Working Group Adoption Poll for "Update… Ketan Talaulikar
- Re: [Lsr] Working Group Adoption Poll for "Update… Robert Raszuk
- Re: [Lsr] Working Group Adoption Poll for "Update… Ketan Talaulikar
- Re: [Lsr] Working Group Adoption Poll for "Update… Robert Raszuk
- Re: [Lsr] Working Group Adoption Poll for "Update… Ketan Talaulikar
- Re: [Lsr] Working Group Adoption Poll for "Update… bruno.decraene
- Re: [Lsr] Working Group Adoption Poll for "Update… Ketan Talaulikar
- Re: [Lsr] Working Group Adoption Poll for "Update… Ketan Talaulikar
- Re: [Lsr] Working Group Adoption Poll for "Update… bruno.decraene
- Re: [Lsr] Working Group Adoption Poll for "Update… Gyan Mishra
- Re: [Lsr] Working Group Adoption Poll for "Update… Robert Raszuk
- Re: [Lsr] Working Group Adoption Poll for "Update… Acee Lindem
- Re: [Lsr] Working Group Adoption Poll for "Update… Robert Raszuk
- Re: [Lsr] Working Group Adoption Poll for "Update… 王亚蓉
- Re: [Lsr] Working Group Adoption Poll for "Update… Ketan Talaulikar
- Re: [Lsr] Working Group Adoption Poll for "Update… Les Ginsberg (ginsberg)
- Re: [Lsr] Working Group Adoption Poll for "Update… bruno.decraene
- Re: [Lsr] Working Group Adoption Poll for "Update… bruno.decraene
- Re: [Lsr] Working Group Adoption Poll for "Update… Ketan Talaulikar
- Re: [Lsr] Working Group Adoption Poll for "Update… Les Ginsberg (ginsberg)
- Re: [Lsr] Working Group Adoption Poll for "Update… Robert Raszuk