Re: [Pals] A question about RFC 6073

"Andrew G. Malis" <agmalis@gmail.com> Tue, 23 January 2024 12:49 UTC

Return-Path: <agmalis@gmail.com>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A817C14F702 for <pals@ietfa.amsl.com>; Tue, 23 Jan 2024 04:49:08 -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 qtkEA_8rs_Jz for <pals@ietfa.amsl.com>; Tue, 23 Jan 2024 04:49:03 -0800 (PST)
Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 AFBB4C14F6A0 for <pals@ietf.org>; Tue, 23 Jan 2024 04:49:03 -0800 (PST)
Received: by mail-pg1-x533.google.com with SMTP id 41be03b00d2f7-5cddfe0cb64so2059903a12.0; Tue, 23 Jan 2024 04:49:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706014143; x=1706618943; 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=oEIAAjDS0ySyU6AXDoI9WGUYfQhvDsLJ7qV7ZO9YJ4Y=; b=QZdi2Q8SRaqlCTM49Yh3tRJUxGacNER26pKl3Af1tO5iP5rqUd3KQIvvVloq1K4Dbf 5N/Vosfp/ThGRBZiNcxlvKiVvvb6O7B81Xorp26/MkHGwfWcolcNX01JWIbOEgwsEUkS AFzT90UjhxyS4K0mzvEvxderRNqcGivfASvahpD66/RNZ7HEU2iUP9lFSSNbTXz/mfHq bS9pnbp0g7e/bMBl05qzQZNmKVH36oeyyxcGKh0LZ6m/NtSc3zTjL1tv2Hf4BvIvmlr2 eqfiV8JSl7BoRZl1DkIDOLHgEXPHy1NDbJwbzz8SRPGSqmZq5FMxFhF87LctVK6dLeJx nh/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706014143; x=1706618943; 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=oEIAAjDS0ySyU6AXDoI9WGUYfQhvDsLJ7qV7ZO9YJ4Y=; b=ZprYFwbclbml46qIGQi1SXfb+4x42+91TrumTNa4gNuNNXSFsWM80Z/Yu+4hLjQOcY TkoEMdb+ekay0PqYSlr5eumqrLoPoUko/YuLeaM8gvyUxhtD6molNQkxrve1T5yTQ8Zb F4iYM+T6PAlddjvQYsRXpUYbDw3ysXGFCEdfKWSxxvPcb+zUi0/x3Z3uSLrC5M+f3OxU epWvN91IP7ucO7ow5zPGJeMFT4XAUceZWDq1hoNj97c4E5V6YjJjF2FYbZnXKwPa942q X3TR4hPhni94CHJreey5RI1Aedlg6OPrO+7pP8IBDdis9jbUYQODE6N+CpW/gx4GApiR XAxw==
X-Gm-Message-State: AOJu0Yz4dTHi7B1QhaBSAUalhn4geofRpVwtUqI0/sgEaiwkEMAJ2RJt ORdMrlEFjVX9Cp5wqHhIPzNgCwW36oOWYAgMbX0aTTtJ8irK0dyJ4n7R4zvBJhPadDYXmiSK7AB oxjlY7NXdjc45iZ8TzlRLiOdWsG4=
X-Google-Smtp-Source: AGHT+IFjvBMKifashioyWur3B+wbjahLiFyPQ3BQUa3nQeQvJoyqoVuePUH1KLdckwpHKdSvAbpuZonczLYSvRt/bWc=
X-Received: by 2002:a17:90a:4811:b0:28e:87a0:c058 with SMTP id a17-20020a17090a481100b0028e87a0c058mr2379434pjh.61.1706014142575; Tue, 23 Jan 2024 04:49:02 -0800 (PST)
MIME-Version: 1.0
References: <PH0PR03MB6300E75656EA7EA5D4E76B65F6742@PH0PR03MB6300.namprd03.prod.outlook.com>
In-Reply-To: <PH0PR03MB6300E75656EA7EA5D4E76B65F6742@PH0PR03MB6300.namprd03.prod.outlook.com>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Tue, 23 Jan 2024 07:48:45 -0500
Message-ID: <CAA=duU0ndN2ijNvidKw-4z4V0Bo1vP3FWiG8iAmp9Jhs3bLJKQ@mail.gmail.com>
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
Cc: "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>, "pals@ietf.org" <pals@ietf.org>, "pwe3@ietf.org" <pwe3@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f33e5b060f9c5ec6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pals/pWkFf01gXi2lZrUNU0Bk03qZcfY>
Subject: Re: [Pals] A question about RFC 6073
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jan 2024 12:49:08 -0000

Sasha,

Here's my two cents, but Matthew may disagree ... :-)

1. No.
2. N/A
3. RFC 4447 states in section 5.4.1 "The PW label should not be withdrawn
unless the operator administratively configures the pseudowire down (or the
PW configuration is deleted entirely)." So the S-PE that detects a local
fault should not withdraw labels instead of sending PW status messages.

Cheers,
Andy


On Tue, Jan 23, 2024 at 2:56 AM Alexander Vainshtein <
Alexander.Vainshtein@rbbn.com> wrote:

> Matthew and all,
>
> I have a couple of questions about what looks to me as an undefined use
> case in RFC 6073 <https://datatracker.ietf.org/doc/html/rfc6073>.
>
>
>
> (These questions should be addressed to all the authors of this RFC, but
> the addresses that appear in the RFC seem to be not relevant anymore).
>
>
>
> On one hand, Section 10.4 of this RFC states that “Pseudowire status
> signaling methodology, defined in [RFC4447], SHOULD be transparent to the
> switching point”.   This suggests to me that S-PE *does not have to be
> aware of the results of the PW Status negotiation by the T-PEs*.
>
>
>
> On the other hand, Section 10.1 of this RFC states that  “ When a local
> fault is detected by the S-PE, a PW status message is sent in both
> directions along the PW”.  This suggest that PW status messages should be
> sent even to T-PEs that do not recognize them and, therefore, would simply
> ignore them.
>
>
>
> Now the questions:
>
>
>
>    1. Should S-PE really be *aware *of the results of the PW Status
>    negotiation between the T-PEs?
>    2. If the answer to my 1st question is “Yes”, should an S-PE that has
>    detected a local fault still send PW Status messages in both directions of
>    the PW?
>    3. If the answer to my 2nd question is “No”, should an S-PE that has
>    detected a local fault withdraw labels it has advertised in both directions
>    of the PW instead of sending PW status messages (probably including
>    appropriate SP-PE TLVs indicating the location of the fault)?
>
>
>
> Your timely feedback would be highly appreciated.
>
>
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
>
>
>
> *Disclaimer*
>
> This e-mail together with any attachments may contain information of
> Ribbon Communications Inc. and its Affiliates that is confidential and/or
> proprietary for the sole use of the intended recipient. Any review,
> disclosure, reliance or distribution by others or forwarding without
> express permission is strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all copies,
> including any attachments.
> _______________________________________________
> Pals mailing list
> Pals@ietf.org
> https://www.ietf.org/mailman/listinfo/pals
>