Re: [Lsr] bunch comments on https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags

Tony Przygienda <tonysietf@gmail.com> Wed, 28 February 2024 07:02 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 2EEACC14CF1D for <lsr@ietfa.amsl.com>; Tue, 27 Feb 2024 23:02:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 FE1QDF-8c5Y3 for <lsr@ietfa.amsl.com>; Tue, 27 Feb 2024 23:02:14 -0800 (PST)
Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 2F870C15154A for <lsr@ietf.org>; Tue, 27 Feb 2024 23:02:14 -0800 (PST)
Received: by mail-ua1-x929.google.com with SMTP id a1e0cc1a2514c-7dacc916452so479337241.0 for <lsr@ietf.org>; Tue, 27 Feb 2024 23:02:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709103733; x=1709708533; 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=N3G7W94WSD0NLSimdzXnE4eUKHZ4L2yg5eRiSYCeGVo=; b=hvqPCJmsTWPe/G/qQEr5R849nQfDkadOFesuVRzaKH+PiQXGK4NkuoQaedUn8twmIg wwZbtHdmTLKEnrYI7MKIt4c2/g/r3VluGdK2gD/4v4mgNaI9nYFmXuUzEEDz3vlI0vCu D7J/xUiNs/jbZKHQ/zAiPp0rbm/OpdXkfNurZxjgIbgToLffSTDS9hg48Zn3DgSKEld4 8xL7z/KmEOtw3xC/oMGcV7cinzQUNdxVV3RQzkYU2E0Kjb9ODi+6hep+lc48OAxdlntK Tum+XPQQfjS4Xl4IrRlsJlxfVSCqDIv82bU6JYhR+janLgFc5VrkcTq5JtScbAYA3L1Z voLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709103733; x=1709708533; 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=N3G7W94WSD0NLSimdzXnE4eUKHZ4L2yg5eRiSYCeGVo=; b=ibuOHgEyZHdS7nFftdie6NELs5x3MG6aS4J3p24+HOpPSkyvwXKxuU7JjUPKN/jNZQ wgxFzdq6Rn6hoxyDW0a6g4MuaeAr9Vppav9aS+rkU+1x/tfTsOZGcSA279+m8129u38G w9bhZH1Zwaexm4H4nyKolhrBRbhXQUchkGrPAPNKlMGdNxIHLNNeSNbLt9avMFNiJo33 /cn9nSz1C7whZzECv5GgEj9v30UgmkDvmyVcAkZx7zGRZGY+UI0hxrrGhaHmaIaYDlGI wnZRXMT+HrG7sipJ/MMqCMAs5ue71Guarh3oSF/1EVFSG4DuorJR/4ICXiiRsF7IlCKf Nm+Q==
X-Gm-Message-State: AOJu0YyXnOiC3ah+AfEAsigBqDfMKQcm11nIiCnLaPruCvPf59owQO4M F8RTW5SX4fvonOz19nDX6vDXTFz0XSDJQVSsltatNOn9EoxfNO/YI5rOE3xm8x3TF3+yN4N4g56 jDqFBlvXf8emZxP0yysibNlkEtLQ=
X-Google-Smtp-Source: AGHT+IGnC8PZtnQa1ozuZ815CUnxBYp7Bn/lWrVS5zX32apOm9yPFPhMAhSoLVtZZJoObatdrbWunPIwYxQjUuGwMGg=
X-Received: by 2002:a05:6102:559b:b0:470:76ea:c7d9 with SMTP id dc27-20020a056102559b00b0047076eac7d9mr8977189vsb.15.1709103732896; Tue, 27 Feb 2024 23:02:12 -0800 (PST)
MIME-Version: 1.0
References: <CA+wi2hMYEN9D3E-BjzX8E8FtEPjgkbN0Yc9F95h42CqLz=u2Rw@mail.gmail.com> <AF6DD69E-AAF2-4CF0-A3B4-774FE72AC58C@gmail.com>
In-Reply-To: <AF6DD69E-AAF2-4CF0-A3B4-774FE72AC58C@gmail.com>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Wed, 28 Feb 2024 08:01:36 +0100
Message-ID: <CA+wi2hP6iFWJGvq28O+tKV1fBJuT73hxLA3B=E9B8cKiYYkWtg@mail.gmail.com>
To: Acee Lindem <acee.ietf@gmail.com>
Cc: lsr <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e23b0606126bb828"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/CunpiIKE-CAqkh-T_dyicFyKZDw>
Subject: Re: [Lsr] bunch comments on https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags
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, 28 Feb 2024 07:02:18 -0000

hey Acee, inline


On Wed, Feb 28, 2024 at 3:30 AM Acee Lindem <acee.ietf@gmail.com> wrote:

> Hi Tony,
>
> Thanks for the review.
>
> On Feb 27, 2024, at 04:51, Tony Przygienda <tonysietf@gmail.com> wrote:
>
> Reading the draft quickly, here's bunch of observations
>
> "
>
>    An OSPF router supporting this specification MUST be able to
>    advertise and interpret at least one 32-bit tag for all type of
>    prefixes.  An OSPF router supporting this specification MAY be able
>    to advertise and propagate multiple 32-bit tags.  The maximum tags
>    that an implementation supports is a local matter depending upon
>    supported applications using prefix tags.
> "
>
> Since different implementations may support different amount of tags I see that the draft says
>
> "
> When propagating multiple tags, the order
>    of the the tags SHOULD be preserved.
>
> "
>
> this is IMO not good enough in case where two nodes advertise same prefix with multiple tags, possibly differing or in different order. Some kind of ordering is necessary then as well AFAIS.
>
>
> I guess I don’t see the problem. A policy would look for a specific tag
> and take a specific action.
>
> Note that for IS-IS tags so require ordering, see section 4 of
> https://datatracker.ietf.org/doc/rfc5130/.
> I could possibly appropriate some of this text as it applies to OSPF.
>
>
my point is that if you have multiple nodes advertising some prefix with
different 3 tag combinations and you choose to only support 3 tags the
result is undefined by this draft as to which tags propagate at the end, so
the "order should be preserved" doesn't help



>
>
>
>
>
> "
>    This sub-TLV will carry one or more 32-bit unsigned integer values
>    that will be used as administrative tags.
> "
>
> IMO behavior when none are carried nees to be specified if this is mandated. is that a MUST in fact?
>
>
>  The sub-TLV is optional so if it isn’t specified than there are no tags
> to match. What am I missing here?
>

it says "one or more" so the sub=-tlv without anything has no semantics. is
that an operational error, is that normal (then why does the draft say one
or more). it's a nit but those nits can be ugly in interops


>
>
>
>
> Moreover we already have a tag in OSPFv2 on type-5 and type-7 and opaque can advertise more tags. How do those interact ?
>
>
>
> I have this text in section 4 to provide backward compatibility:
>
>    When tags are advertised for AS External or NSSA LSA prefixes, the
>
>    existing tag in the OSPFv2 and OSPFv3 AS-External-LSA and NSSA-LSA
>    encodings SHOULD be utilized for the first tag.  This will facilitate
>    backward compatibility with implementations that do not support this
>    specification.
>
>
oh, I missed that. sorry.


>
> Thanks,
> Acee
>
>
>
>
> that's it for the first
>
> thanks
>
> -- tony
>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>
>