[Teas] Re: Comments abount rfc2205 Resource ReSerVation Protocol (RSVP)

[Tuấn Anh Vũ <[e-mail]>]

Hi,
Thanks for all your answers, please find my view below:
I./ For *Adrian:*

Vào Th 4, 23 thg 10, 2024 vào lúc 01:23 Vishnu Pavan Beeram <
[e-mail]> đã viết:

> AnhVT, Hi!
>
>
>
> Since you are referring to an LSP in an IP/MPLS network, I’m assuming that
> you are using in-band RSVP signaling. I’m 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’t 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 PM Adrian Farrel <[e-mail]> wrote:
>
>> Hi Anh,
>>
>>
>>
>> [Redirecting from MPLS to TEAS as suggested by Tony Li]
>>
>>
>>
>> I think that (given you mention LSPs) you re talking about RSVP-TE (RFC
>> 3209) not plain old RFC 2205 RSVP.
>>
>>
>>
>> In your example, the link R2-R3 has failed in a way that R3 is aware of
>> the failure, but R2 is not aware.
>>
>>
>>
>> There are two questions that arise…
>>
>>    1. Why isn’t 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 “by sending a PathErr or ResvTear or Notification”. 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.
>>
>>
>>
>> Cheers,
>>
>> Adrian
>>
>>
>>
>> *From:* Tuấn Anh Vũ <[e-mail]>
>> *Sent:* 22 October 2024 04:45
>> *To:* [e-mail]
>> *Subject:* [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
>> _______________________________________________
>> Teas mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>