Return-Path: <anhvt.hdg@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by ietfa.amsl.com (Postfix) with ESMTP id 888DDC229190
	for <mpls@ietfa.amsl.com>; Mon, 21 Oct 2024 20:39:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level: 
X-Spam-Status: No, score=-2.107 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]
	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 nvjkPx8bXbpS for <mpls@ietfa.amsl.com>;
	Mon, 21 Oct 2024 20:39:15 -0700 (PDT)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [IPv6:2a00:1450:4864:20::533])
	(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 29D4BC229185
	for <mpls@ietf.org>; Mon, 21 Oct 2024 20:39:15 -0700 (PDT)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5c937b5169cso665749a12.1
        for <mpls@ietf.org>; Mon, 21 Oct 2024 20:39:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1729568353; x=1730173153; darn=ietf.org;
        h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=vOaB2bQ6jaOKqnBYiT5saxMYJZ4CMsK7IjDkzi4/Vis=;
        b=fkFEBlJCMJv8B2EGC18V0mlQXr9cBSqFILnLrp67EvUY/VFUL+Wzs39oQqudp2dQtM
         zkdNWBAmI07yeYKPxPCoFxrDVOjXLCY7VvEeqJYHDuluT3AEOBVFbWgD6nYE78MrAKjA
         +FR9t+CuAjBLGb1f1xzYM8A0y0C8O5kiQbWW5D5rvGuQK4Q6GuOxwRhYJi2STn13pBOS
         8XJitUzNrMITBxbyCLocUr5HD1yLo85U9NNk7xg5QTIQvM/eRkU/6n/0giwCVdDIBYLU
         f5muEyKMGCJ86IUru1aLI9+DVtDtw3xPZo7eheaAwbSAi96ombGOctxmNlQgz94otB0Y
         0YSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1729568353; x=1730173153;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=vOaB2bQ6jaOKqnBYiT5saxMYJZ4CMsK7IjDkzi4/Vis=;
        b=cvjWS/xXHQC3GPbi86/XYO1O9npgpImZJWJuw7vo+FoEaqK128a9J7gzoOUXkHGMWU
         BXkMKIJIykQw9NJeiv8PJ7lYujPYHxcJpKH5uG6+XCyprsQ8vyUqpAxAI/V2N/LUGks2
         oyzKBMrEC5wCGTdQJshiFK8PCZoWsTEgYS3Fp1uNS25s0N4R77Xsf6vD0boRA+etx+k4
         uTXc/l5FZgsSHk6E0uFuD2y154XgNOFKsopElU4qePOil6BUwfLx5l0kT/gzhmNQYBSe
         5qQgVAih6cqqvp9YwxewN3PncPGOUZEfK4mf2P4ODYWqgQ0NeXBBh8GOCpqBGCKb3sAE
         gegA==
X-Gm-Message-State: AOJu0Yx86KN4oWJQOfjB6whhs7kbmDTJt59nGo/eNOvdXW/GTShpkRfM
	sUIUDQlDkBjM3gtIEzLVmIsdX9anFOVmFOFKX2MJV1J91Ec8kNfl+CtqtokqAUqlAPfPlfNCO4p
	cSwFVgAHMhRIFauE5D1n4Fj87uEt7G+tDuuY=
X-Google-Smtp-Source: 
 AGHT+IGXH7bV5VvUBhdZ//jF2H2K6RCLUgi2PTRTpstWiTEDxt2zCDpfVKK3WztU2uD9RVl980jMBXruKjZI2q661jQ=
X-Received: by 2002:a05:6402:3496:b0:5c9:3f1:e5cd with SMTP id
 4fb4d7f45d1cf-5cb793bfeafmr1937153a12.0.1729568353252; Mon, 21 Oct 2024
 20:39:13 -0700 (PDT)
MIME-Version: 1.0
From: =?UTF-8?B?VHXhuqVuIEFuaCBWxak=?= <anhvt.hdg@gmail.com>
Date: Tue, 22 Oct 2024 10:44:38 +0700
Message-ID: 
 <CA+SXWCnrL-0AbHKJo_k0RNhVP-maJQqkwfdaZfx4wo82eKYO=w@mail.gmail.com>
To: mpls@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004f7f01062508830c"
Message-ID-Hash: 2NJ2ZFAH2VHTT2INKYJF7JQQLOXMBLZY
X-Message-ID-Hash: 2NJ2ZFAH2VHTT2INKYJF7JQQLOXMBLZY
X-MailFrom: anhvt.hdg@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency;
 loop; banned-address; member-moderation; header-match-mpls.ietf.org-0;
 nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size;
 news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: =?utf-8?q?=5Bmpls=5D_Comments_abount_rfc2205_Resource_ReSerVation_Protocol_?=
	=?utf-8?q?=28RSVP=29?=
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/mpls/2yu5YOVMSWbpwFDUUkd3reqr2jM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Owner: <mailto:mpls-owner@ietf.org>
List-Post: <mailto:mpls@ietf.org>
List-Subscribe: <mailto:mpls-join@ietf.org>
List-Unsubscribe: <mailto:mpls-leave@ietf.org>

--0000000000004f7f01062508830c
Content-Type: text/plain; charset="UTF-8"

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

--0000000000004f7f01062508830c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi IETF team,<div>I&#39;m AnhVT from the SVTech company in=
 VietNam, I have experienced=C2=A0some RSVP issues in the IPv4 MPLS network=
.</div><div>I suspect that RSVP has a point that needs to be enhanced. I de=
scribe=C2=A0this point below:</div><div><br></div><div>I./ Topology:</div><=
div><font face=3D"monospace">=C2=A0 =C2=A0 ---------LSP--------&gt;</font><=
/div><div><font face=3D"monospace">=C2=A0 =C2=A0 R1----R2----R3-----R4</fon=
t></div><div><font face=3D"monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=
=C2=A0 =C2=A0 /</font></div><div><font face=3D"monospace">=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 |=C2=A0 /</font></div><div><font face=3D"monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0R5</font></div><div><font face=3D"ari=
al, sans-serif">II./ Issue</font></div><div><font face=3D"arial, sans-serif=
">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 dow=
n, then it deletes the LSP state and sends the PathTear downstream to R4.</=
font></div><div><font face=3D"arial, sans-serif">2./Because R2 does not rec=
ognize the interface flap,</font><span style=3D"font-family:arial,sans-seri=
f">=C2=A0R2 still keeps it</span><span style=3D"font-family:arial,sans-seri=
f">=C2=A0available.</span><span style=3D"font-family:arial,sans-serif">=C2=
=A0It does not know that the LSP should be deleted.</span></div><div><font =
face=3D"arial, sans-serif">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 for=
warding traffic to the LSP, This makes the service down.</font></div><div><=
font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, =
sans-serif">III./ My comment</font></div><div><font face=3D"arial, sans-ser=
if">I think that RSVP needs a mechanic=C2=A0so that R3 signals to R2 to ens=
ure that R2 knows that R3 deleted the LSP. Based on that signal, R2 will br=
ing down the LSP and continue to send Reserve Tear to R1.</font></div><div>=
<font face=3D"monospace"><br></font></div><div><font face=3D"arial, sans-se=
rif">I hope that you take a look at my comment.</font></div><div><font face=
=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-seri=
f">Regards,</font></div><div><font face=3D"arial, sans-serif">AnhVT</font><=
/div></div>

--0000000000004f7f01062508830c--

