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

[Alexander Vainshtein <[e-mail]>]

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.