[bess] Re: Murray Kucherawy's No Objection on draft-ietf-bess-evpn-mh-pa-11: (with COMMENT)
"Murray S. Kucherawy" <superuser@gmail.com> Thu, 05 December 2024 15:11 UTC
Return-Path: <superuser@gmail.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED8CC151076; Thu, 5 Dec 2024 07:11:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 XBI89QkNavfs; Thu, 5 Dec 2024 07:11:24 -0800 (PST)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3497C151068; Thu, 5 Dec 2024 07:11:24 -0800 (PST)
Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-a9e44654ae3so157405566b.1; Thu, 05 Dec 2024 07:11:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733411483; x=1734016283; 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=KjyYweADFvW6quoPlAFJQCGhlSco96Etfd9u13blzNs=; b=evnN+jUxipzd5GVmHSkiScp78O+YE8SehkFV5JHfiGTNyGMR42+7FaaV5x6lchtvL8 tGwGwR6a6xj5KzjR3KlCYIxMKpqYViyKzrMC5TMPKo/24lzxCKwaq+m0nZxLxhrGqW38 MqMzrHVYn8lB6DXOeedEu7AQv1ud49Lc5Hn9WT2mrrTPMuGPNurcEx+Ix9f/k7HKkFwj rwtyRf9ROwr3vJU91aKAuNk5ueVrQVNb3PGtiyP62lFy1ryFdhldwYqXHZ77eNj43MZW nK8D9KxScTGziNxyAQQZEp5Pgg9OgP8tpIvPMd/n2WcP9nJKW7YmDn8b96WCX+I4wBuP /hcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733411483; x=1734016283; 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=KjyYweADFvW6quoPlAFJQCGhlSco96Etfd9u13blzNs=; b=fLI3esL2yJHn6wqTrNP6w1TWoDv+7m9Y2eKdSU09Kz0Rm216ArAl8K/oui8ii660RI CG62PrM9s3tkoW2YDz/iSjbLKFf9xICSbhLqQPbOJ5vA5+bUi/+5mEo/SntfiHJ6VXvy LWZykOlRTNO3K0phCmrJihktpggXdyYPIosKo121tUZLYGsAXzfW+gHPVfetlhwb/khM ool6YIXjKrloCbFUclhbfdwavs1HcsiP6lC/TEc9QKaJ2GEt9Hb1rGeA/Uy0cBUMbOVK Go56YozitDVuEH1F9JivE+rY4jT4ta1BM3SRIJp+hLxS9qWl7n71E5ANBGvA5hIj6uO1 0EgA==
X-Forwarded-Encrypted: i=1; AJvYcCVnB7sBBdZcM3J71vc0Qf+tSYAiIB0N7GS8sY687CoDRk0UhlLmPxJ23eOszTqL6olbRo0dkOjyLRRnOw==@ietf.org, AJvYcCWI2Ih5Z+U9biW8KAO43O1TLqbpr1MK7jY03D8FSOmiZibVo9M7GLFnZ+0XmOhpX2AldjFsLS0xhgoZ5bbJ8lmOqXs4H+jgLPTDjd8=@ietf.org, AJvYcCX5Ykp9hqfQR8jKo2mzlCB2Z/n2RtBMCCRQDl7HcX+POz2+oS6vd6bm1kl6cxOll2+SUxm7TQ==@ietf.org
X-Gm-Message-State: AOJu0Yz85Gf6zXrBIOTY16M0yRhsbD6lWkyr+kztx9tte/X4pOdFqozX 30rhYWVKQ07sUw2QA7QS5wSV2kbTqcZGsvyyLoPf3CYd35tZ0e8Rs9PnTFsvC/+3zZVhKqKYv/I MwwmG5y70IuVDO+qkwYtbacP2kKM=
X-Gm-Gg: ASbGncvnpv0lhgnu4mPUanMVuN+al7pNn7O+P/7Ka+Ls/Az6TLm1YCT+8Gyd+gNRQni vE8WKGLbVMz//KkFVRE72zm/JSy7U3tQ=
X-Google-Smtp-Source: AGHT+IGMpg1OhvMj4wD7YZvh6FAGp5moGcZ3iSNyPTDKNvOuF8hiddHgYX109Fz8HiKpIWDvgHP4n62vbGHqZ6u1AVI=
X-Received: by 2002:a17:906:30ce:b0:aa6:26c3:4a5a with SMTP id a640c23a62f3a-aa626c34ac0mr273958666b.52.1733411482831; Thu, 05 Dec 2024 07:11:22 -0800 (PST)
MIME-Version: 1.0
References: <173337616026.1929542.5305027267934263347@dt-datatracker-5679c9c6d-qbvvv> <SA1PR11MB8492030417E83303CC91FA4FBC302@SA1PR11MB8492.namprd11.prod.outlook.com>
In-Reply-To: <SA1PR11MB8492030417E83303CC91FA4FBC302@SA1PR11MB8492.namprd11.prod.outlook.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Thu, 05 Dec 2024 07:11:10 -0800
Message-ID: <CAL0qLwY3tJ2TpKpCv6Vh-pH1cAnKLtJtiHXJT_6Mxi=mEZFgug@mail.gmail.com>
To: "Luc Andre Burdet (lburdet)" <lburdet@cisco.com>
Content-Type: multipart/alternative; boundary="000000000000af152d0628874f59"
Message-ID-Hash: F2UCXMHVQ246FN2FR2METS7KDEWFGGUU
X-Message-ID-Hash: F2UCXMHVQ246FN2FR2METS7KDEWFGGUU
X-MailFrom: superuser@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-bess.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: The IESG <iesg@ietf.org>, "draft-ietf-bess-evpn-mh-pa@ietf.org" <draft-ietf-bess-evpn-mh-pa@ietf.org>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "slitkows.ietf@gmail.com" <slitkows.ietf@gmail.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [bess] Re: Murray Kucherawy's No Objection on draft-ietf-bess-evpn-mh-pa-11: (with COMMENT)
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/fhqmi1Ujv5KQk011qQEXn_UvVoc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Owner: <mailto:bess-owner@ietf.org>
List-Post: <mailto:bess@ietf.org>
List-Subscribe: <mailto:bess-join@ietf.org>
List-Unsubscribe: <mailto:bess-leave@ietf.org>
On Thu, Dec 5, 2024 at 6:04 AM Luc Andre Burdet (lburdet) <lburdet@cisco.com> wrote: > The normative SHOULD was used because it is possible to operate in > Port-Active mode without the P/B in Ether A-D per ES (if port-active is > setting the interface Down then the peer will not send any routes – there > is no ‘B’). > Would someone ever choose to do that? If so, why? If this is just for backward compatibility, there are other alternatives like saying new implementations MUST do (new thing), and SHOULD accept (old thing) for backward compatibility. It is just undesirable for convergence: the P/B give a hint to the remote > that the entire port is Primary vs Backup, and that it need not wait for > each individual Ether A-D per EVI update to P/B. > That sounds a lot like a MAY to me. > All implementations I am aware of are doing it, but I should still circle > back to co-authors/implementors before flipping it to a MUST. > OK, sounds good. -MSK
- [bess] Murray Kucherawy's No Objection on draft-i… Murray Kucherawy via Datatracker
- [bess] Re: Murray Kucherawy's No Objection on dra… Luc Andre Burdet (lburdet)
- [bess] Re: Murray Kucherawy's No Objection on dra… Murray S. Kucherawy