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

[Adrian Farrel <[e-mail]>]

Hello again,

 

I’m 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ấn Anh Vũ <[e-mail]> 
Sent: 24 October 2024 08:32
To: Vishnu Pavan Beeram <[e-mail]>
Cc: [e-mail]; TEAS WG <[e-mail]>
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ào Th 4, 23 thg 10, 2024 vào lúc 01:23 Vishnu Pavan Beeram <[e-mail] <mailto:[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] <mailto:[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] <mailto:[e-mail]> > 
Sent: 22 October 2024 04:45
To: [e-mail] <mailto:[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] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]>