[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 > >
- [Teas] Re: [mpls] Re: [EXTERNAL] Comments about r… Joel Halpern
- [Teas] Re: [mpls] Re: [EXTERNAL] Comments about r… Tuấn Anh Vũ