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

[Ron Bonica <[e-mail]>]

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:
--------------------------------------------------------------------