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

[Alexandre Petrescu <[e-mail]>]

For clarification of terms: 'institutional memory' stands for someone 
expressing common experiences of facts of that group, remembering past 
events in great detail.

The term 'institutional' has nothing to do with an institution, contrary 
to appearances, but might have to do with the 'constituency' of the 
group, a bit twisted.

It is a new term circulated in certain groups.

Alex

Le 12/06/2024 à 16:34, Adrian Farrel a écrit :
>
> 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]>
> *Sent:* Tuesday, June 11, 2024 5:37 PM
> *To:* 'Brian E Carpenter' <[e-mail]>; Ron Bonica 
> <[e-mail]>; 'Ole Troan' <[e-mail]>; '6man WG' 
> <[e-mail]>
> *Cc:* '6man Chairs' <[e-mail]>; 
> [e-mail] 
> <[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]>
> Sent: 11 June 2024 21:25
> To: Ron Bonica <[e-mail]>; Ole Troan 
> <[e-mail]>; 6man WG <[e-mail]>
> Cc: 6man Chairs <[e-mail]>; 
> [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]
> Administrative Requests:
> --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests:
> --------------------------------------------------------------------