[Teas] Re: [mpls] Re: [EXTERNAL] Comments about rfc2205 Resource ReSerVation Protocol (RSVP)

Tuấn Anh Vũ <anhvt.hdg@gmail.com> Fri, 01 November 2024 02:05 UTC

Return-Path: <anhvt.hdg@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9650CC1CAF5A for <teas@ietfa.amsl.com>; Thu, 31 Oct 2024 19:05:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, 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 NiY_72E8nWcY for <teas@ietfa.amsl.com>; Thu, 31 Oct 2024 19:05:51 -0700 (PDT)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 C0C9AC180B79 for <teas@ietf.org>; Thu, 31 Oct 2024 19:05:51 -0700 (PDT)
Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-5c937b5169cso2471044a12.1 for <teas@ietf.org>; Thu, 31 Oct 2024 19:05:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730426750; x=1731031550; 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=7ktIHXgEKZ7jkUT7LkY9K9T/6/ynJN8qGup9REOtUbE=; b=XLKbKZBXhwGW/zDFISsBjN7CPqVk/bwq3RQai1hxTKsogPYpEXg3yPCU231X0fQsv/ 9SQ3L29Pw4zYM5u7MX3FctP+UFb47Bfqo367h2j4yrxKnV60Aa9DlxNW+Ke/lBJ6yLeg 3+UtIdbOmmaa1va5W0PjDie2NvlGiv1tzSfH/7GglQ/haYQxG3MbmHjzxkAvX+R+Fb4d Z2y271ChjRL/nEIgHp8GVDr2J58CyC6oFRF6VW20AFvV3ukrhL8YYIti+Zr5Geq47PJ2 FnNWAUa9+JH4rKstknwB34L8E5YXhqMTMZtSdvR8VNJJLyjG8XA27p21iwp6+yVTQyd7 AaiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730426750; x=1731031550; 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=7ktIHXgEKZ7jkUT7LkY9K9T/6/ynJN8qGup9REOtUbE=; b=vFO/3L5Ew/+1VOaJ9e6uq+yBTuTdgBfwQ7AyOKzMMPbmwWXLSeNdqXDzygdO8hH665 nOAYAi37s0+P6uErwifJy5KnYy+us9aMMh/EcW6UDJmnZz42roYqouwUl0Qa2C/cupAq 89XXk29N3vCg++JkRFVisK50HFcGBJ27ArqWzL/HbiHAwRWGrrTpGBYoi8vLsuSQ3FiH qy5EYCAzzEIIwNZ7PJeFpim/BzVuQok+KMavTfoeqmYnOUSArzbq0wF0e83T+94Z2t2R NQay3TVZ18cxBTSKTLFYgeP816pbmtaMHJUhfwfQIMfegE5bdFyD2fr0u3sUmDWcKB0K el5w==
X-Gm-Message-State: AOJu0YxukEBa6qMFgqJaOqlsWjjYCW1mJQ06fhXtQpG9wODkkWgsLTGM gP13Q/1KqBvsJLHDEINAu8iXC6y4zGHF16rCpUJleUtt6hQU74hDpnL7yT/qCLznCUSZgAeIEWS 2qOnRuu2LydHuHJz0ZtNYjGuFOyFrtDKifyc=
X-Google-Smtp-Source: AGHT+IGT1QAs4Zs2bviGOgVYYOwqqe0UPB38S4wW7KXuYgVFCM23F/dKDNTD/sFvJee8an9+0UV1ExWewpXVpVjrbp4=
X-Received: by 2002:a05:6402:2546:b0:5cb:7318:15ef with SMTP id 4fb4d7f45d1cf-5ceb8d0d505mr2094159a12.10.1730426749898; Thu, 31 Oct 2024 19:05:49 -0700 (PDT)
MIME-Version: 1.0
References: <CA+SXWCnrL-0AbHKJo_k0RNhVP-maJQqkwfdaZfx4wo82eKYO=w@mail.gmail.com> <PH0PR03MB63002D4AFEEC38B9D6729611F64C2@PH0PR03MB6300.namprd03.prod.outlook.com> <041a01db26e8$104ea7e0$30ebf7a0$@olddog.co.uk> <CA+SXWCm-3H-6L4HbT1T=B7wQ32zX-gb5PHHwhaj5AA9g=_xB=w@mail.gmail.com> <7b3adfbc-4935-4719-8e98-8779b9e00fc6@joelhalpern.com>
In-Reply-To: <7b3adfbc-4935-4719-8e98-8779b9e00fc6@joelhalpern.com>
From: Tuấn Anh Vũ <anhvt.hdg@gmail.com>
Date: Fri, 01 Nov 2024 09:05:39 +0700
Message-ID: <CA+SXWCkgCGovsiiuM+2uXA32fvpfospfh3RTrSSFAiE6Kg7ZTw@mail.gmail.com>
To: Joel Halpern <jmh@joelhalpern.com>
Content-Type: multipart/alternative; boundary="000000000000bcdbee0625d05f35"
Message-ID-Hash: BHFF5CSYDKYJS4EUXFC2Y4EQZ6IZN4UH
X-Message-ID-Hash: BHFF5CSYDKYJS4EUXFC2Y4EQZ6IZN4UH
X-MailFrom: anhvt.hdg@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-teas.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "teas@ietf.org" <teas@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Teas] Re: [mpls] Re: [EXTERNAL] Comments about rfc2205 Resource ReSerVation Protocol (RSVP)
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/8jn64GgoSKyFztciD37iBoJS3CE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Owner: <mailto:teas-owner@ietf.org>
List-Post: <mailto:teas@ietf.org>
List-Subscribe: <mailto:teas-join@ietf.org>
List-Unsubscribe: <mailto:teas-leave@ietf.org>

Hi Joel,
Thanks for your email.
I agree that we have some protocols to support RSVP-TE to detect the link
issue faster (exp: bfd, ...). But in some cases, the router deleted the LSP
state for other reasons, not only link failure. I just think that RSVP
should have its mechanic to avoid such of issue.

Regards,
AnhVT

Vào Th 4, 30 thg 10, 2024 vào lúc 01:44 Joel Halpern <jmh@joelhalpern.com>
đã viết:

> I am trying to parse the case.  Restating to label things.  For some
> RSVP-TE based LSP router A is upstream of router B over link C. The link
> between A and B flaps.  A does not notice. A is not running BFD to provide
> backup detection.  B does notice.  Having noticed, B deletes the path state.
>
> If I understand your ask, you want B to send A a notice that it has
> deleted the path state.  To do so, it would need to save the information
> until the link comes back (which happens to be quickly in your
> hypothetical), and then send the notice.  And hope that the notice gets
> through before the link flaps again?    It seems BFD is well-designed for
> this problem, and is a general mechanism with rather than putting in a
> complex special behavior into RSVP-TE?  Am I missing some added value in
> bundling this into RSVP-TE?
>
> In a different hypothetical, for example if B deleted the state due to
> resource exhaustion, I could see attempting to send the notification
> upstream.  But that is not what you seem to have requested.
>
> Yours,
>
> Joel
> On 10/29/2024 3:05 AM, Tuấn Anh Vũ wrote:
>
> Hi Adrian, Sasha,
> I agree that we have BFD to detect the link issue. But just think that
> RSVP-TE should have its mechanic to ensure the router signals both
> downstream and upstream when the LSP soft-state is deleted.
> There are many causes leading to the issue of one router clearing the soft
> state, not just the issue I listed in the email; it is just one example.
>
> Regards,
> AnhVT
>
> Vào Th 6, 25 thg 10, 2024 vào lúc 21:13 Adrian Farrel <
> adrian@olddog.co.uk> đã viết:
>
>> I agree with Sasha, here.
>>
>>
>>
>> It seems that you should not be relying on RSVP-TE to detect link
>> failures. If the hardware cannot be relied to catch the problems, then BFD
>> seems like the right tool.
>>
>>
>>
>> RSVP-TE **is** soft state. But that means it cleans up after errors, not
>> that it can be (or should be) used to detect network problems.
>>
>>
>>
>> Cheers,
>>
>> Adrian
>>
>>
>>
>> *From:* Alexander Vainshtein <Alexander.Vainshtein=
>> 40rbbn.com@dmarc.ietf.org>
>> *Sent:* 22 October 2024 10:54
>> *To:* Tuấn Anh Vũ <anhvt.hdg@gmail.com>
>> *Cc:* mpls@ietf.org
>> *Subject:* [mpls] Re: [EXTERNAL] Comments about rfc2205 Resource
>> ReSerVation Protocol (RSVP)
>>
>>
>>
>> AnhVT hi!
>>
>>
>>
>> Have you considered running very fast 1-hop IP-BFD (RFC 5881) between R2
>> and R3, possibly combined with setting something like hold-time up (or its
>> equivalent in your specific equipment – a mechanism that reduces link
>> flapping by delaying propagation of physical UP events to L3 entities on
>> this port)?
>>
>>
>>
>> My guess is that such a combination would result in bi-directional
>> detection of link going down by 1-hop IP-BFD, and your RSVP problem would
>> then disappear.
>>
>>
>>
>>
>>
>> Regards,
>>
>> Sasha
>>
>>
>>
>> *From:* Tuấn Anh Vũ <anhvt.hdg@gmail.com>
>> *Sent:* Tuesday, October 22, 2024 6:45 AM
>> *To:* mpls@ietf.org
>> *Subject:* [EXTERNAL] [mpls] Comments abount rfc2205 Resource
>> ReSerVation Protocol (RSVP)
>>
>>
>>
>> Hi IETF team,
>>
>> I'm AnhVT from the SVTech company in VietNam, I have experienced some
>> RSVP issues in the IPv4 MPLS network.
>>
>> I suspect that RSVP has a point that needs to be enhanced. I
>> describe this point below:
>>
>>
>>
>> I./ Topology:
>>
>>     ---------LSP-------->
>>
>>     R1----R2----R3-----R4
>>
>>           |    /
>>
>>           |  /
>>
>>            R5
>>
>> II./ Issue
>>
>> 1./ Because of some bugs (exp: R3 experiences a flap link between R3-R2,
>> but R2 does not recognize the interface flap), R3 indicates that LSP is
>> down, then it deletes the LSP state and sends the PathTear downstream to R4.
>>
>> 2./Because R2 does not recognize the interface flap, R2 still keeps
>> it available. It does not know that the LSP should be deleted.
>>
>> 3./ Due to 1./ and 2./ R1 does not know that the LSP is stuck because R3
>> and R4 deleted the LSP state, and R1 continues forwarding traffic to the
>> LSP, This makes the service down.
>>
>>
>>
>> III./ My comment
>>
>> I think that RSVP needs a mechanic so that R3 signals to R2 to ensure
>> that R2 knows that R3 deleted the LSP. Based on that signal, R2 will bring
>> down the LSP and continue to send Reserve Tear to R1.
>>
>>
>>
>> I hope that you take a look at my comment.
>>
>>
>>
>> Regards,
>>
>> AnhVT
>>
>>
>>
>> *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.
>>
>
> _______________________________________________
> mpls mailing list -- mpls@ietf.org
> To unsubscribe send an email to mpls-leave@ietf.org
>
>