Return-Path: 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 1D88EC151543 for ; Thu, 24 Oct 2024 00:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=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=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=olddog.co.uk 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 Bh2PcDawsGYh for ; Thu, 24 Oct 2024 00:57:03 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B315C14F6F2 for ; Thu, 24 Oct 2024 00:57:01 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.7/8.14.7) with ESMTP id 49O7uwGD008395; Thu, 24 Oct 2024 08:56:58 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0E95A4604B; Thu, 24 Oct 2024 08:56:58 +0100 (BST) Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 024A946048; Thu, 24 Oct 2024 08:56:58 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS; Thu, 24 Oct 2024 08:56:57 +0100 (BST) Received: from LAPTOPK7AS653V (196.15.90.146.dyn.plus.net [146.90.15.196]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.7/8.14.7) with ESMTP id 49O7uuhx028014 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Oct 2024 08:56:57 +0100 From: "Adrian Farrel" To: "=?utf-8?Q?'Tu=E1=BA=A5n_Anh_V=C5=A9'?=" , "'Vishnu Pavan Beeram'" References: <007301db2471$b5124760$1f36d620$@olddog.co.uk> In-Reply-To: Date: Thu, 24 Oct 2024 08:56:55 +0100 Organization: Old Dog Consulting Message-ID: <02ce01db25ea$4b6a8a50$e23f9ef0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02CF_01DB25F2.AD33FB60" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJs191CpzwTDbRYx8MHfnPA1pdkPQNCwzHKAdfM0e0BvmsXIbE7XKJg Content-Language: en-gb X-Originating-IP: 146.90.15.196 X-Thinkmail-Auth: adrian@olddog.co.uk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=20221128; bh=PvcqlpV9kc5PpcdELJNIz KX1czwJljEEOW50nSpwnJM=; b=Z1epbDCuiN3Tamcu7XUYL4kzQKnqZRRgBDf+w GY1Uvn4bIDGK//N2KfDo9A7iDDKcwpPpEcf8CLecoYuMSUpZ1PZZH3CYN0Cl15As UGrvT0Ohm5pMQFs5X5a4NfYfMkT99dXaq9RNR7Jz37ZV0G7GKSQvGFlV6S3NP1RF 5jmYwP+78x0E+vvFkWFW9s4gAnh+eSaIORzveXvArm7RgkjgTBqpVjqsa0RqnZ4e vXo5TYgZ7JDG8PIIFXUcO5zVLgxoROvz81yp9tEshxUr6WoK3yURg3xHj/g5+kT6 AqGuH9mnP96Fc/w2mKH+s3fCuDzvr45sfo9BCaAKCTavu6nVA== X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-28352.003 X-TM-AS-Result: No--41.403-10.0-31-10 X-imss-scan-details: No--41.403-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-28352.003 X-TMASE-Result: 10--41.402700-10.000000 X-TMASE-MatchedRID: CxmI61mtwh/aYagUwgwslHFPUrVDm6jtE2cpTKk2QcOghGjfPV9/adXo aDx6LsWMzIO4dXAjcKoXLF2kpvCVLF0ieHN50/kHjrVn4cme+w4bTwzYj2zQuo0aTATCSWEVdev CkD7aZESw+sZesF51YeU/CKnn+dHIleWb3UW/Uik6HG6H9FokcRyZZXVVr0zuFn5QQLJDBBL8GY fDM0qx/L5wpZVCbFHLzQ4WFoNross7K/upbxRpcvwCyINrEjhrTSz0JdEAJbRPTA0ugRYgKmimI zb1qb1PVyPMvYp13OROBA3mkBUxA+H51ZqVVrxF4kw0h+3MIJNZ+CK+BxQ9k3y/Hx1AgJrrO+WR k1kOc5OsnS86lxaByQkHfdGEySYtXHqPGIIXXFrHM1p4NoWygxmJMshC7hikyPRAwD/3abbOxZd IoBn2VDq0KNPTKJlEgZN7o8KpvqSr9kYr30jJYA2bPyoJqnZLEsgNhd10hiJS7xGqYsNk9bM1m2 4REs33033oYXU6sdUoipXMvIJYrfepys9WAF85PPov5T+l6PEi/Fg9lUzpJWUbQLBPRl8kWPB5g J72ENYvcv4jhXl4I9ud7w4DXt6uI7nwgt67vfDvVbHa5Rs8t0OvwxWboMrdW2L+irfrhdj1O9p2 Fcb2DeA+pVvNiWVRG/MSNjg92e3sg8vFfJU1lGQYj6+BFPEwUaTm5EfQzMJHpEd1UrzmFdo4FZo SpQ8Yqh9drh/jR8JUIeWBPbgx+4M8neyDXeYn7kIYxuaO6ZShHrZE2+S869kY+KIbxMxzdXXYCB SZPZZKkAU17gNQnhEIYgqT6DwinDY0xTYUoiN9dWbpg7kae30tCKdnhB58r10pknZXGJqy5/tFZ u9S3M+9+OQ9U/5f33fj+sMArfNRzX47Vf0DMQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 Message-ID-Hash: MTP2QCUY4H6AO3EEH77TV5MO2KUQJKVX X-Message-ID-Hash: MTP2QCUY4H6AO3EEH77TV5MO2KUQJKVX X-MailFrom: adrian@olddog.co.uk 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 WG' X-Mailman-Version: 3.3.9rc6 Precedence: list Reply-To: adrian@olddog.co.uk Subject: =?utf-8?q?=5BTeas=5D_Re=3A_Comments_abount_rfc2205_Resource_ReSerVation_Prot?= =?utf-8?q?ocol_=28RSVP=29?= List-Id: Traffic Engineering Architecture and Signaling working group discussion list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_02CF_01DB25F2.AD33FB60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello again, =20 I=E2=80=99m having trouble seeing any additional comments from you in = this mail thread. This is possibly an error with my mailer, but I also checked your mail = in the archive at = https://mailarchive.ietf.org/arch/msg/teas/f-X48hcljP-hk0Tj_Hfb36yLxSM/ =20 Thanks, Adrian =20 From: Tu=E1=BA=A5n Anh V=C5=A9 =20 Sent: 24 October 2024 08:32 To: Vishnu Pavan Beeram Cc: adrian@olddog.co.uk; TEAS WG Subject: [Teas] Re: Comments abount rfc2205 Resource ReSerVation = Protocol (RSVP) =20 Hi, Thanks for all your answers, please find my view below: I./ For Adrian: =20 V=C3=A0o Th 4, 23 thg 10, 2024 va=CC=80o lu=CC=81c 01:23 Vishnu Pavan = Beeram > = =C4=91=C3=A3 vi=E1=BA=BFt: AnhVT, Hi! =20 Since you are referring to an LSP in an IP/MPLS network, I=E2=80=99m = assuming that you are using in-band RSVP signaling. I=E2=80=99m also = assuming that this is an LSP that does not have any form of = local-protection enabled. =20 When R3 detects an upstream link-down event, it cleans up the local path = state and sends a PathTear downstream -- in this scenario, the onus is = not on R3 to notify the ingress of this outage. The typical expected = behavior on R2 is to detect the downstream link-down event and send a = PathErr to the ingress (signaled hop-by-hop) of the LSP. R2 would also = clean-up the reservation state and send a ResvTear to the ingress = (again, signaled hop-by-hop). If R2 is not able to detect the link-down = event for some reason (and no other link state detection mechanism like = BFD is available), there are a couple of control-plane options that RSVP = already provides to clean up state (in due course of time) and bring = down the LSP: * Stale state cleanup based on soft state time out (RFC2205): Since the = link is down, the reservation state isn=E2=80=99t getting refreshed. So, = when the reservation state times out (in about 157.5 secs for a = refresh-interval of 30 secs), R2 is expected to clean-up the reservation = state and signal a ResvTear to the ingress * Use of RSVP Hello Session based on the Node-ID (RFC4558) for detection = of RSVP-TE signaling adjacency failure: If there was an RSVP Hello = session maintained between R2 and R3, R2 would be able to couple the = state of the LSP with the state of signaling adjacency. And when the = signaling adjacency failure is detected (Hello State timed out -- for a = 9 sec hello interval, the time out takes 31.5 secs), R2 would clean up = the reservation state and signal a ResvTear to the ingress. This option = can be used to clean up stale state when long refresh intervals are = used. =20 Hope this helps. =20 Regards, -Pavan =20 On Tue, Oct 22, 2024 at 4:34=E2=80=AFPM Adrian Farrel = > wrote: Hi Anh, =20 [Redirecting from MPLS to TEAS as suggested by Tony Li] =20 I think that (given you mention LSPs) you re talking about RSVP-TE (RFC = 3209) not plain old RFC 2205 RSVP. =20 In your example, the link R2-R3 has failed in a way that R3 is aware of = the failure, but R2 is not aware. =20 There are two questions that arise=E2=80=A6 1. Why isn=E2=80=99t R2 able to notice? Presumably the link failure = detection is relying on a lower layer (L2 or L1) failure indication, and = that is not happening. The answer to this is to run some other link = failure detection mechanism such as BFD. Such a mechanism would allow R2 to declare the link down and possibly = re-route/repair the LSP via R5, or notify the head end (R1) to let it = re-route. 2. How could R3 let R2 know that the LSP has been torn down? The answer = is =E2=80=9Cby sending a PathErr or ResvTear or Notification=E2=80=9D. = In general, those messages are sent hop by hop, and so they would fail = to be routed on the failed link R3-R2, however, it is possible to = IP-tunnel to direct-address RSVP packets so that they would be IP-routed = to R2 (or direct to R1) via R5. =20 Cheers, Adrian =20 From: Tu=E1=BA=A5n Anh V=C5=A9 >=20 Sent: 22 October 2024 04:45 To: mpls@ietf.org =20 Subject: [mpls] Comments abount rfc2205 Resource ReSerVation Protocol = (RSVP) =20 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: =20 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. =20 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. =20 I hope that you take a look at my comment. =20 Regards, AnhVT _______________________________________________ Teas mailing list -- teas@ietf.org =20 To unsubscribe send an email to teas-leave@ietf.org = =20 ------=_NextPart_000_02CF_01DB25F2.AD33FB60 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello = again,

 

I=E2=80=99m = having trouble seeing any additional comments from you in this mail = thread.

This is possibly an error with my = mailer, but I also checked your mail in the archive at = https://mailarchive.ietf.org/arch/msg/teas/f-X48hcljP-hk0Tj_Hfb36yLxSM/

 

Thanks,

Adrian

 

From: Tu=E1=BA=A5n Anh = V=C5=A9 <anhvt.hdg@gmail.com>
Sent: 24 October 2024 = 08:32
To: Vishnu Pavan Beeram = <vishnupavan@gmail.com>
Cc: adrian@olddog.co.uk; TEAS WG = <teas@ietf.org>
Subject: [Teas] Re: Comments abount = rfc2205 Resource ReSerVation Protocol = (RSVP)

 

Hi,

Thanks for = all your answers, please find my view below:

I./ For Adrian:

 

V=C3=A0o Th 4, 23 thg 10, 2024 va=CC=80o lu=CC=81c = 01:23 Vishnu Pavan Beeram <vishnupavan@gmail.com> = =C4=91=C3=A3 vi=E1=BA=BFt:

AnhVT, = Hi!

 

Since you are referring to an = LSP in an IP/MPLS network, I=E2=80=99m assuming that you are using = in-band RSVP signaling. I=E2=80=99m also assuming that this is an LSP = that does not have any form of local-protection = enabled.

 

When R3 detects an upstream = link-down event, it cleans up the local path state and sends a PathTear = downstream -- in this scenario, the onus is not on R3 to notify the = ingress of this outage. The typical expected behavior on R2 is to detect = the downstream link-down event and send a PathErr to the ingress = (signaled hop-by-hop) of the LSP. R2 would also clean-up the reservation = state and send a ResvTear to the ingress (again, signaled hop-by-hop). = If R2 is not able to detect the link-down event for some reason (and no = other link state detection mechanism like BFD is available), there are a = couple of control-plane options that RSVP already provides to clean up = state (in due course of time) and bring down the = LSP:

  • Stale state cleanup based on = soft state time out (RFC2205): Since the link is down, the reservation = state isn=E2=80=99t getting refreshed. So, when the reservation state = times out (in about 157.5 secs for a refresh-interval of 30 secs), R2 is = expected to clean-up the reservation state and signal a ResvTear to the = ingress
  • Use of RSVP Hello Session based = on the Node-ID (RFC4558) for detection of RSVP-TE signaling adjacency = failure: If there was an RSVP Hello session maintained between R2 and = R3, R2 would be able to couple the state of the LSP with the state of = signaling adjacency. And when the signaling adjacency failure is = detected (Hello State timed out -- for a 9 sec hello interval, the time = out takes 31.5 secs), R2 would clean up the reservation state and = signal a ResvTear to the ingress. This option can be used to clean up = stale state when long refresh intervals are = used.

 

Hope this = helps.

 

Regards,

-Pavan

 

On Tue, Oct 22, 2024 at 4:34=E2=80=AFPM Adrian Farrel = <adrian@olddog.co.uk> = wrote:

Hi = Anh,

 <= /o:p>

[Redirecting= from MPLS to TEAS as suggested by Tony Li]

 <= /o:p>

I think = that (given you mention LSPs) you re talking about RSVP-TE (RFC 3209) = not plain old RFC 2205 RSVP.

 <= /o:p>

In your = example, the link R2-R3 has failed in a way that R3 is aware of the = failure, but R2 is not aware.

 <= /o:p>

There are = two questions that arise=E2=80=A6

  1. Why isn=E2=80=99t R2 able to notice? Presumably the link = failure detection is relying on a lower layer (L2 or L1) failure = indication, and that is not happening. The answer to this is to run some = other link failure detection mechanism such as = BFD.

Such a mechanism would allow R2 to declare = the link down and possibly re-route/repair the LSP via R5, or notify the = head end (R1) to let it re-route.

  1. How could R3 let R2 know that the LSP has been torn down? = The answer is =E2=80=9Cby sending a PathErr or ResvTear or = Notification=E2=80=9D. In general, those messages are sent hop by hop, = and so they would fail to be routed on the failed link R3-R2, however, = it is possible to IP-tunnel to direct-address RSVP packets so that they = would be IP-routed to R2 (or direct to R1) via = R5.

 <= /o:p>

Cheers,=

Adrian<= /o:p>

 <= /o:p>

From: Tu=E1=BA=A5n Anh = V=C5=A9 <anhvt.hdg@gmail.com>
Sent: 22 = October 2024 04:45
To: mpls@ietf.org
Subject: [mpls] Comments = abount rfc2205 Resource ReSerVation Protocol = (RSVP)

 <= /o:p>

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:

 <= /o:p>

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.

 <= /o:p>

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.

 <= /o:p>

I hope that you take a look at = my comment.

 <= /o:p>

Regards,

AnhVT

_______________________________________________
Teas= mailing list -- teas@ietf.org
To unsubscribe send an email to = teas-leave@ietf.org

------=_NextPart_000_02CF_01DB25F2.AD33FB60--