[IPv6]Re: Adoption call for draft-bonica-6man-deprecate-router-alert

[Brian E Carpenter <[e-mail]>]

Thanks for that enlightnment. I think capturing some of this (maybe in an Appendix) would help the readers of deprecate-router-alert, since RSVP is the classical reason why we had router alert in the first place.

Regards
    Brian Carpenter

On 13-Jun-24 02:34, Adrian Farrel wrote:
> I know of several implementations I was involved with that either stopped using RAO completely, or made it off by default but allowed it to be configured.
> 
> But that’s a long way from being able to claim “most implementations”.
> 
> Time for a survey?
> 
> A
> 
> *From:*Ron Bonica <[e-mail]>
> *Sent:* 12 June 2024 15:21
> *To:* 'Brian E Carpenter' <[e-mail]>; 'Ole Troan' <[e-mail]>; '6man WG' <[e-mail]>; [e-mail]
> *Cc:* '6man Chairs' <[e-mail]>; [e-mail]
> *Subject:* Re: [IPv6]Re: Adoption call for draft-bonica-6man-deprecate-router-alert
> 
> Adrian,
> 
> Thanks for this excellent history. Your institutional memory is, as usual, amazing.
> 
> Am I right in saying that today, most RSVP-TE implementations *do not*​use the IPv4 Router Alert by default?
> 
>                                                                                                        Ron
> 
> P.S.:  I remember many of the RFCs that you cite. But I was a mere lad in those days 😉
> 
> Juniper Business Use Only
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> *From:*Adrian Farrel <[e-mail] <mailto:[e-mail]>>
> *Sent:* Tuesday, June 11, 2024 5:37 PM
> *To:* 'Brian E Carpenter' <[e-mail] <mailto:[e-mail]>>; Ron Bonica <[e-mail] <mailto:[e-mail]>>; 'Ole Troan' <[e-mail] <mailto:[e-mail]>>; '6man WG' <[e-mail] <mailto:[e-mail]>>
> *Cc:* '6man Chairs' <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> *Subject:* RE: [IPv6]Re: Adoption call for draft-bonica-6man-deprecate-router-alert
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Brian,
> 
> RFC 2205 section 3.11.5 says:
> 
>                Packets received for IP protocol 46 but not addressed to
>                the node must be diverted to the RSVP program for
>                processing, without being forwarded.  The RSVP messages to
>                be diverted in this manner will include Path, PathTear,
>                and ResvConf messages.  These message types carry the
>                Router Alert IP option, which can be used to pick them out
>                of a high-speed forwarding path.  Alternatively, the node
>                can intercept all protocol 46 packets.
> 
> The "alternatively" branch indicates how the interception may be done without relying on RAO.
> Of course, 2205 says that the RAO must be set by the sender. However, that is a little ambiguous because the same section goes on to say:
> 
>                RSVP must be able to cause Path, PathTear, and ResvConf
>                message to be sent with the Router Alert IP option.
> 
> RFC 2961 started to dilute the requirement to use RAO with section 3.3:
> 
>     RSVP Bundle messages SHOULD NOT be sent with the Router Alert IP
>     option in their IP headers.  This is because Bundle messages are
>     addressed directly to RSVP neighbors.
> 
> RFC 3473 (RSVP-TE for GMPLS) introduced a variation in section 10.2 as:
> 
>     When a node is sending a Path, PathTear or ResvConf message to a node
>     that it knows to be adjacent at the data plane (i.e., along the path
>     of the LSP), it SHOULD address the message directly to an address
>     associated with the adjacent node's control plane.  In this case the
>     router-alert option SHOULD not be included.
> 
> ...and this is continued in RFC 5150.
> 
> There is various discussion (e.g., RFC 4206, RFC 4804) of end-to-end RSVP and RSVP aggregation and non-use of RAO. But that's a bit of a special case.
> 
> Of course, there is general advice and guidance in RFC 6398. It doesn't so much describe how to do RSVP without RAO, as suggest environments where you shouldn't use it.
> 
> Cheers,
> Adrian
> 
> -----Original Message-----
> From: Brian E Carpenter <[e-mail] <mailto:[e-mail]>>
> Sent: 11 June 2024 21:25
> To: Ron Bonica <[e-mail] <mailto:[e-mail]>>; Ole Troan <[e-mail] <mailto:[e-mail]>>; 6man WG <[e-mail] <mailto:[e-mail]>>
> Cc: 6man Chairs <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Subject: [IPv6]Re: Adoption call for draft-bonica-6man-deprecate-router-alert
> 
> Ron,
> 
> For my education:
> 
> <snip>
> 
>  > - new work. What if there is a new protocol requiring a punt out of the forwarding path by an intermediate router? Isn’t HBH + Router Alert the easiest and most performant way for the forwarding plane to do that? Alternatively we’ll end up with magic cookies like STUN (0x2112A442). Where the forwarding plane would have to parse the EH chain before looking at a cookie.
>  >
>  > [RB] Could you tell me more about such protocols. Specifically, why could they not use the same strategy that RSVP used when it moved away from the Router Alert Option.
> 
> Where do I find the spec for RSVP without Router Alert?
> 
> Thanks
>       Brian
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail] <mailto:[e-mail]>
> Administrative Requests:
> --------------------------------------------------------------------
>