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

[Joel Halpern <[e-mail]>]

I am trying to parse the case.  Restating to label things.  For some 
RSVP-TE based LSP router A is upstream of router B over link C. The link 
between A and B flaps.  A does not notice. A is not running BFD to 
provide backup detection.  B does notice.  Having noticed, B deletes the 
path state.

If I understand your ask, you want B to send A a notice that it has 
deleted the path state.  To do so, it would need to save the information 
until the link comes back (which happens to be quickly in your 
hypothetical), and then send the notice.  And hope that the notice gets 
through before the link flaps again?    It seems BFD is well-designed 
for this problem, and is a general mechanism with rather than putting in 
a complex special behavior into RSVP-TE?  Am I missing some added value 
in bundling this into RSVP-TE?

In a different hypothetical, for example if B deleted the state due to 
resource exhaustion, I could see attempting to send the notification 
upstream.  But that is not what you seem to have requested.

Yours,

Joel

On 10/29/2024 3:05 AM, Tuấn Anh Vũ wrote:
> 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.
>
>
> _______________________________________________
> mpls mailing list [e-mail]
> To unsubscribe send an email [e-mail]