Re: [Pals] A question about RFC 6073

Alexander Vainshtein <Alexander.Vainshtein@rbbn.com> Tue, 06 February 2024 16:07 UTC

Return-Path: <alexander.vainshtein@rbbn.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 9FFD5C14F683 for <pals@ietfa.amsl.com>; Tue, 6 Feb 2024 08:07:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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, 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 (1024-bit key) header.d=rbbn.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 7ssZYBKfnz2W for <pals@ietfa.amsl.com>; Tue, 6 Feb 2024 08:07:51 -0800 (PST)
Received: from usb-smtp-delivery-110.mimecast.com (usb-smtp-delivery-110.mimecast.com [170.10.153.110]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 5DC7AC14F61A for <pals@ietf.org>; Tue, 6 Feb 2024 08:07:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20230413; t=1707235669; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=o+VwDXmGLRkTegIo7LOm243LM9WpvBdWilU7V4Tycok=; b=bQhpu9dfP/ZLHd40+ydBlYbA61eeRCtMFxiQl69F1p7GSR9YIzSqFLYFhS4N8lEyDrKOdi 1r3gi4ZToKSR1gu+SYw0iU4sT6zmhEbdMKFPWx0fvbp/fhHzsskDVDHniAI8CxWSc6ChFF r8tCkaYEvGZQnSbKIHOix8c+aMfmYCQ=
Received: from BL2PR02CU003.outbound.protection.outlook.com (mail-eastusazlp17012018.outbound.protection.outlook.com [40.93.11.18]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id usb-mta-6-OFkwA4iLOXuBucmWz9vADw-1; Tue, 06 Feb 2024 08:03:04 -0800
X-MC-Unique: OFkwA4iLOXuBucmWz9vADw-1
Received: from PH0PR03MB6300.namprd03.prod.outlook.com (2603:10b6:510:e2::5) by MW4PR03MB6946.namprd03.prod.outlook.com (2603:10b6:303:1bd::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7249.36; Tue, 6 Feb 2024 15:59:02 +0000
Received: from PH0PR03MB6300.namprd03.prod.outlook.com ([fe80::c771:5454:2384:e312]) by PH0PR03MB6300.namprd03.prod.outlook.com ([fe80::c771:5454:2384:e312%5]) with mapi id 15.20.7249.035; Tue, 6 Feb 2024 15:59:02 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
To: "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>
CC: "pals@ietf.org" <pals@ietf.org>
Thread-Topic: A question about RFC 6073
Thread-Index: AdpNzs9PUwabeQhsTf+KiH1JeNFEHAED89HwAc2xsNA=
Importance: high
X-Priority: 1
Date: Tue, 06 Feb 2024 15:59:02 +0000
Message-ID: <PH0PR03MB6300B1EE8E6F5A173AD91CEBF6462@PH0PR03MB6300.namprd03.prod.outlook.com>
References: <PH0PR03MB6300E75656EA7EA5D4E76B65F6742@PH0PR03MB6300.namprd03.prod.outlook.com> <PH0PR03MB6300BFBE99FEE6F8D58D0AD7F67F2@PH0PR03MB6300.namprd03.prod.outlook.com>
In-Reply-To: <PH0PR03MB6300BFBE99FEE6F8D58D0AD7F67F2@PH0PR03MB6300.namprd03.prod.outlook.com>
Accept-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH0PR03MB6300:EE_|MW4PR03MB6946:EE_
x-ms-office365-filtering-correlation-id: 43a2f0e2-893e-4153-32dc-08dc272c89b3
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0
x-microsoft-antispam-message-info: m+pl+6T+FBn3xge3VgLa2XkNZksgZ4RU7TJas1yBCPgsOb6uwi3O0tIZ2xN92foP8pAnqMXcb7G1zyCSobGDe55rg/gBplldcxZRNLY/498Id1rADIKY58B2fx3sGVMy6rSdWeqnkThPHz/W8prZxNOZVMudtRVpCYXWbL3eOaemlNeBBPKgVl6OZ4KQ5cRCySJ+lDj65Ifz0yRVvgLaRZNQinrHn9bkCNFHRlH805G9Bk9WNWUrpvMAH+UF4/h3z9/YUavG/OebXDvzTJURzBsKbfIA2UgeSfFCjwxX9ThiKqUbY7tv78FfhHDTRwqS2iUlvSPww+VkVadMHc8we64y0cW8l0Nux3Uc1XkMYXmnU6ly0TKHuCoieItTMo18ItHNbS1ETHNDqaL6hUhn9U3EH1e0DHONg1TarKmo/1tch89VDyH9HBBHpz23AhQ2+QjIrpJuFXYPS60+CHlisLOyNZNYZT2oQ1vyD1JDh3bBcEMsWkACbyMDY3rATQ4UknKAOLOX/d/BR5/jCoLvv0WvSgXS5mlnWkFX0RcfYSVQmeHDwRf+aiP33UZo7LWcLJ8+eGeOO8nxyRMO5Dk35gqnOXt+nvJGpv1DwMqRorI=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR03MB6300.namprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(346002)(39860400002)(136003)(366004)(376002)(396003)(230922051799003)(186009)(451199024)(1800799012)(64100799003)(2906002)(55016003)(5660300002)(41300700001)(86362001)(83380400001)(99936003)(66574015)(122000001)(166002)(9686003)(6506007)(53546011)(7696005)(6916009)(33656002)(64756008)(478600001)(71200400001)(296002)(316002)(26005)(38100700002)(66446008)(38070700009)(52536014)(66476007)(8676002)(8936002)(4326008)(66556008)(66946007)(76116006); DIR:OUT; SFP:1102
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: /vMR708zDcFmUffAXk4/iCEpmiVTcs+5+9cIl2tL8cAY8mYziAkcsVY7+G2Q7SNzQFONwqFVwIA3LJmcgCNOLVtm2t3Y/3wRBFJJS5RITpE+CTzbCeM9HJvM4yYHSg3EwHU42Ajbf+bKbA6yNcRlGJ8lLVgyvlbKpDLtnh6BdglDXLimSv5cyD9NJKYWdjfCYsBVICeYQT0lxreiZ3AbK5DV4McV7p9lGv/yBS7sCSNtC8DeXu4MPbEF4RQsUwKfthayrNgduVgAHW8MAzYv6Bt+nRNtKaRsFhxN1Zn6n+B7cQVDMVLQotW/IXaLyYA50fjGHTf/2L5j8zZibGUsb79RKFf+5BvHqpUXMxHMSQwEkZiU9ZtZDik5EXkomazHKi8H6yJP2dxRxClitmcoOGLDkb4AzIIqX53IJrElqJ+F/uZKjHB+xd+bR/a2VlthhUHrTBudoMrbQCzv8o96RKZ+ec47hhaajaK1/Fub9kn7FLd4eZBh7/y79OGgLj1BnAE9GGKZ2HH+oOhMWoX6nMVufNHcD3qIjvmL6QgsMr8XxAFHCxnFgwjHRBQ+RnEiWvWT66axABCFaKpWIH7Fi22iTKJcYhhrf5eYC1earlwhphbyfvb0yhT1QGfqtdzwOFRanoB9NedN12If4YxHvxqlpqnVzT49CVzkLXyaZn0VCWVRxLZ82AiO1OX9JZjxi0EnJJCGuhyFem10wOg105pOuqbH14IxrdzYWAd8jsD3ccX1wRyqH1NN/u+nfk5h4FgrM8Q/UpAIwJuGpMcTyl1b2pNHSthG9CPMoRSrXzxZYj3UykPeZCjzcjGgIBrKNEqgQFFUC8mP8wxsvzUdsBj0lHBchVniEXyyPUaAYSCmXSkP6MTLxGIUIb2QOjw48+fwZE7c/V3MrdexSDq7RkJpLSQeDWheU+9JC5f25/Vu7wRcrBhu89rUfx1VzIWopb6aMHgX7fxm2lcxd69Mv+n3cMe6xqNzwOoc6MvcL8xDfgsFnRORI96ZNZ3S9RwhuV+YrdyBV3TGTRgVBeCJsLKPDEncGyD0TwixKMa+Ln5/VTWIm5lh0bkffYlfFsshsDkqLW8sndvOPxg9BGYN2Hqw17JvSauv8fc2iqWjpjCRLD+W1l6ZCKMAoJcc7hbZF38Q8aS1Fc7Dai+vuXOgNbvudUzrptqoqo9eIKv0oHtymGlRdIDesALpCTRJuTYiobaCjAg5nrPcrV2C0arGSPd57XqnB6K03FCJQEV2SG5LgFdctN6yTBf7/G/lCl4LXzi9yBTGZDs0nciBcsPHjtWgG6EhdvWJPTAlNcy8p21h9bhJgZFx2+V18GpeUMGL6kwf2njsT//QuPsDs0NdDNCGDZ9MSqGSlW8fHj4nZZ82fR0wK+Gyl2Wv5Cp5m12qsOEyiwRG6lbQuDL1NvlcBDOr4d18XEeSTs5aEKh2czSCq/kAKYXjmAtn9saR4qvmuS/8t+NZwj9HCI8oni0P6xm4hdymNNBM6H3h65CdlFxNUZnSHm6LaB/9KV/yNbvt6Cuix4Op5DYZDn+DLeok2XAD8DhMQS84WMdiW5zFYT1RGzigOwlH26AHT7TdPzHh
MIME-Version: 1.0
X-OriginatorOrg: rbbn.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR03MB6300.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 43a2f0e2-893e-4153-32dc-08dc272c89b3
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2024 15:59:02.1845 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 2K2s5GCYJO+t8B0U2DHzcnRQ0Ew3AjcFmE+371MUFOydnCKBGlgJAB5GXX6HpW7PdZUltIwwbjBtyI4sbtRJMA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR03MB6946
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: rbbn.com
Content-Language: en-US
Content-Type: multipart/related; boundary="_004_PH0PR03MB6300B1EE8E6F5A173AD91CEBF6462PH0PR03MB6300namp_"; type="multipart/alternative"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pals/sAERrW0psd3ERXl25kys9d6Gai8>
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, 06 Feb 2024 16:07:55 -0000

Matthew and all,
Regarding my question about handling of failure of LDP session between S-PE and one of its peers after some Label Mapping messages have been received from this peer and "propagated" to the other peer.

IMHO and FWIW the analog of this scenario for BGP-based services  is failure of a BGP session between the "domain border router" and one of its client PEs in the inter-domain Option B (see EVPN Inter-domain Option B draft<https://datatracker.ietf.org/doc/html/draft-rabadan-bess-evpn-inter-domain-opt-b-02>) scenario for "bridging EVPN" (RFC 7432) and/or EVPN-VPWS (RFC 8214).

In this case the expected behavior is quite clear: failure of a BGP session means that the "domain border router" treats all routes learned via the failed session as if they were withdrawn and withdraws all the routes it has re-advertised based on these routes.

Personally I do not see why S-PEs in the case of signaled MS-PWs should behave differently.

What do you think?

Regards,
Sasha

From: Alexander Vainshtein
Sent: Sunday, January 28, 2024 1:58 PM
To: Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com>
Cc: pals@ietf.org; pwe3@ietf.org
Subject: RE: A question about RFC 6073

Matthew and all,
One more question about yet another undefined use case in RFC 6073<https://datatracker.ietf.org/doc/html/rfc6073>.

The reference topology for this use case is shown in the diagram below.

[cid:image002.png@01DA5926.28D64010]
Suppose that initially:

·       All LSP session shown in the diagram have been successfully established

·       T-PE1 has sent a Label Mapping message to S-PE-1 that advertises some L1 for FEC-128 with the PW ID=100

·       Consequently, S-PE1 (which, according to Section 7.2 of RFRC 6-73 takes a passive role) locally allocates label L2 and advertises it to S-PE2 in a Label Mapping message for FEC-128 with PW ID 200.
Now my question:
What should happen if the LDP session between T-PE1 and S-PE1 fails?
Specifically, should S-PE1 send a Label Withdraw message for the label L2 and FEC-128 with PWID 200?
My personal (and, probably, naïve) answer is that L2 should be withdrawn because, if LDP session between T-PE1 and S-PE1 were not established, S-PE1 would not receive the original Label Mapping message from T-PE1 and, therefore, would not advertise Label 2 for FEC-128 with PW ID 100 to S-PE2.

My colleagues have observed at least one implementation of S-PE that simply does not do anything in this case. This does not look right to me - but I have not found any explicit definitions for handling this scenario in RFC 6073.

Your feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha

From: Alexander Vainshtein
Sent: Tuesday, January 23, 2024 9:56 AM
To: Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com<mailto:matthew.bocci@nokia.com>>
Cc: pals@ietf.org<mailto:pals@ietf.org>; pwe3@ietf.org<mailto:pwe3@ietf.org>
Subject: A question about RFC 6073
Importance: High

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.