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

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

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 <[e-mail]>
đã 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=
> [e-mail]>
> *Sent:* 22 October 2024 10:54
> *To:* Tuấn Anh Vũ <[e-mail]>
> *Cc:* [e-mail]
> *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ũ <[e-mail]>
> *Sent:* Tuesday, October 22, 2024 6:45 AM
> *To:* [e-mail]
> *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.
>