Subject: Thoughts on draft-bonica-6man-deprecate-router-alert

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 2 Jan 2022 18:28:56 -0000

In general, I am not opposed to the idea of "banning" future uses of the
router alert option in IPv6.

I believe that the word "deprecate" is wrongly used in this document in that
this document does not make the router alert option obsolete. Indeed, the
Abstract says "Protocols that use the Router Alert Option may continue to do
so." So, let's make the document say what it is saying, viz., "The IPv6
router alert option is not to be used in any new protocols or any new
protocol extensions."

Some nits...

   *  The control plane sends routing protocol messages through the
      forwarding plane to other nodes.

I think it "may" do that, but it can also send routing protocol messages
through the management plane or the control plane which are not necessarily
congruent with the forwarding plane.
(Additionally, this bullet occurs under "The forwarding and control planes
communicate with one another as follows:" yet this bullet is an example of
the control plane elements communicating with each us via the forwarding
plane, not the two planes communicating with each other.)

---

I find a slight difficulty in the term "control plane". I think it would be
helpful to talk about "control plane components/elements" for the processing
pieces, and recall that the control plane is those elements *plus* the
channels between them.

---

   NOTE: In RFC 6398, the terms "fast path" and "control plane
   components" are used synonymously.

Are they? I don't think so. "Fast path" relates to processing in the
forwarding plane. "Control plane components" are on the slow path.

---

Along with RFC 8029, you should probably consider and reference RFC 7506

---

While it is widely agreed that RSVP-TE (i.e., the MPLS control plane use of
RSVP) implementations should/do not use the router alert option, it is
hellishly hard to find where that is documented as a prohibition in IPv6 (or
IPv4). And, of course, the RSVP spec says that you do use it, so a naif
implementer of RSVP-TE might assume you should (I'm fairly sure one of the
WGs - MPLS? - did a survey on this, but I can't find it).

---

Section 4 seems a little frail and possibly it is aspirational rather than
factual.

---

Rather than mark the Router Alert value as Deprecated in
https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-
parameters-2, isn't what you really want to do is go to
https://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-va
lues.xhtml#ipv6-routeralert-values-1 and make 70-65502 Reserved [RFC8126]
with a reference to this RFC. That seems more consistent with allowing the
old uses to continue the way you describe.

---

Best,
Adrian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 3 Jan 2022 08:54:57 +1300

On one point only:

> this document does not make the router alert option obsolete.

I disagree. The word "deprecate" has no formal status in the IETF standards
process, so there is no rule here. In other SDOs (for example, the Fortran
standards process), "deprecate" is used rather precisely, so a feature that
is "deprecated" in version N is expected to be removed in version N+1,
explicitly breaking backwards compatibility. But we don't have that concept
in the IETF process, and we tend to prefer backwards compatibility for
operational reasons, as this draft does.

One of the Merriam-Webster definitions of "deprecate" is
"to withdraw official support for or discourage the use of
(something, such as a software product) in favor of a newer
or better alternative." That seems to cover this case.

We've used this sense for many years, eg in RFC2578:
'While the value "deprecated" also indicates an obsolete definition,
it permits new/continued implementation in order to foster
interoperability with older/existing implementations.'

Apart from that, IMHO Adrian's comments are spot on. But don't forget to
update RFC8504 too.

Regards
    Brian

On 03-Jan-22 07:28, Adrian Farrel wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 2 Jan 2022 21:03:49 -0000

Hi Brian,

Shall we argue English language semantics? 😊

> process, so there is no rule here.

I agree that there is no formal status in the IETF (where is Barry when you need him?), but I disagree that there is "no rule here." Normal English meaning holds.

> or better alternative." That seems to cover this case.

Precisely not!
The draft states clearly that the use by protocols/implementations that already use it may continue.
That is not discouraging the use of.
And it is on that basis that I argue "deprecate" is wrongly used.

> interoperability with older/existing implementations.'

Ah, so you argue precedent to create a de facto formal status for the word? 

Best,
Adrian

PS - I don't *really* care about this, but I hate to see language abused.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 3 Jan 2022 01:27:58 +0100

> And it is on that basis that I argue "deprecate" is wrongly used.

+1

It’s not like the features that rely on router alerts are going away (unfortunately — I wish we actually *could* deprecate router alerts, instead of just marking them NRND).

> PS - I don't *really* care about this, but I hate to see language abused.

Ditto…

Grüße, Carsten

---

From: Fred Baker <[email-masked]>
Date: Sun, 2 Jan 2022 16:59:17 -0800

Sent using a machine that autocorrects in interesting ways...

> On Jan 2, 2022, at 1:04 PM, Adrian Farrel <[email-masked]> wrote:
> 

I would argue that IETF use of the word derives primarily from SNMP, wherein it is in fact defined. An SNMP object which is deprecated is mandatory to implement (but one doesn’t have to request it) in the version in question, but may be removed entirely in a subsequent version.

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 2 Jan 2022 19:25:31 -0800

> I would argue that IETF use of the word derives primarily from SNMP, wherein it is in fact defined. An SNMP object which is deprecated is mandatory to implement (but one doesn’t have to request it)…

One could argue that is possible to implement router alert handling and 
also ignore it, in the case of the  control-plane protocols  described 
in the draft there is zero value wrt to the route-alert option as far as 
identifying that these packets need forwarding to the control plane. 
they are forwarded to the control plane because the destination whether 
it is a multicast address or one of the control-planes IPs is bound to 
to control-plane processor.

---

From: Ron Bonica <[email-masked]>
Date: Tue, 4 Jan 2022 16:17:41 +0000

Hi Brian,

Are you sure that 8504 needs to be updated? Section 14.1 appears to be accurate, even after the RAO is deprecated.

                                                                                        Ron

Juniper Business Use Only

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: Sunday, January 2, 2022 2:55 PM
To: [email-masked]; '6MAN' <[email-masked]>; [email-masked]
Subject: Re: Thoughts on draft-bonica-6man-deprecate-router-alert

[External Email. Be cautious of content]

On one point only:

> I believe that the word "deprecate" is wrongly used in this document 
> in that this document does not make the router alert option obsolete.

I disagree. The word "deprecate" has no formal status in the IETF standards process, so there is no rule here. In other SDOs (for example, the Fortran standards process), "deprecate" is used rather precisely, so a feature that is "deprecated" in version N is expected to be removed in version N+1, explicitly breaking backwards compatibility. But we don't have that concept in the IETF process, and we tend to prefer backwards compatibility for operational reasons, as this draft does.

One of the Merriam-Webster definitions of "deprecate" is "to withdraw official support for or discourage the use of (something, such as a software product) in favor of a newer or better alternative." That seems to cover this case.

We've used this sense for many years, eg in RFC2578:
'While the value "deprecated" also indicates an obsolete definition, it permits new/continued implementation in order to foster interoperability with older/existing implementations.'

Apart from that, IMHO Adrian's comments are spot on. But don't forget to update RFC8504 too.

Regards
    Brian

On 03-Jan-22 07:28, Adrian Farrel wrote:
> In general, I am not opposed to the idea of "banning" future uses of 
> the router alert option in IPv6.
>
> I believe that the word "deprecate" is wrongly used in this document 
> in that this document does not make the router alert option obsolete. 
> Indeed, the Abstract says "Protocols that use the Router Alert Option 
> may continue to do so." So, let's make the document say what it is 
> saying, viz., "The IPv6 router alert option is not to be used in any 
> new protocols or any new protocol extensions."
>
> Some nits...
>
> I think it "may" do that, but it can also send routing protocol 
> messages through the management plane or the control plane which are 
> not necessarily congruent with the forwarding plane.
> (Additionally, this bullet occurs under "The forwarding and control 
> planes communicate with one another as follows:" yet this bullet is an 
> example of the control plane elements communicating with each us via 
> the forwarding plane, not the two planes communicating with each 
> other.)
>
> ---
>
> I find a slight difficulty in the term "control plane". I think it 
> would be helpful to talk about "control plane components/elements" for 
> the processing pieces, and recall that the control plane is those 
> elements *plus* the channels between them.
>
> ---
>
> hellishly hard to find where that is documented as a prohibition in 
> IPv6 (or IPv4). And, of course, the RSVP spec says that you do use it, 
> so a naif implementer of RSVP-TE might assume you should (I'm fairly 
> sure one of the WGs - MPLS? - did a survey on this, but I can't find it).
>
> ---
>
> Section 4 seems a little frail and possibly it is aspirational rather 
> than factual.
>
> ---
>
> https://urldefense.com/v3/__https://www.iana.org/assignments/ipv6-para
> meters/ipv6-parameters.xhtml*ipv6-__;Iw!!NEt6yMaO-gk!Rrg9b4EAKfaeHDm0r
> GvIc_LL7CWSfaNNG9Qv2pQc5mMiYQQH5iGTWz_8QDXlxbBm$
> https://urldefense.com/v3/__https://www.iana.org/assignments/ipv6-rout
> eralert-values/ipv6-routeralert-va__;!!NEt6yMaO-gk!Rrg9b4EAKfaeHDm0rGv
> Ic_LL7CWSfaNNG9Qv2pQc5mMiYQQH5iGTWz_8QN-m-9E2$
> lues.xhtml#ipv6-routeralert-values-1 and make 70-65502 Reserved 
> [RFC8126] with a reference to this RFC. That seems more consistent 
> with allowing the old uses to continue the way you describe.
>
> ---
>
> Best,
> Adrian
>
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!Rrg9b4EAKfaeHDm0rGvIc_LL7CWSfaNNG9Qv2pQc5mMiYQQH5iGTW
> z_8QCuPxqql$

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Jan 2022 08:38:48 +1300

> Are you sure that 8504 needs to be updated? Section 14.1 appears to be accurate, even after the RAO is deprecated.

Yes, but as I said a couple of days ago, there is nothing in 8504 to warn a product manager about the deprecation. I may be naive, but I imagine that a product manager might use "Node requirements" as their principal guidance for product requirements.

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 5 Jan 2022 02:15:18 +0100

My thoughts:

a) There is also RFC3208 (PGM) that was implemented and for a while used
   widely. I am not sure if there are impleemntations supported over IPv6,
   but if this document goes forward, it should be listed.

b) I have worked with several of the listed protocols (and PGM) extensively,
   including in customer deployments. I find the mechanism provided by
   router-alert to be very fundamental to intelligent network operations
   and when implemented correctly to be well working not only inside
   single administrative domains but likely in multi-administrative-domain
   networks, such as those of financial service providers connecting
   producers of data (such as exchanges) and consumers (brokers).

c) I would not count any of the deployments where i am seeing router-alert
   as being useful and working as RFC6398 "independent administrative
   domains in the Internet", so RFC6398 to the extend it is cited in the
   draft is fine, but does not limit the use of router alert where i have
   seen it being very useful.

   I therefore can not not count the listed bullet points from 
   RFC6398 as justifications for deprecation.

d) I can only see one original? argument made to support deprecation,
   and that is the cost of fast-path examination of IPv6 extension
   headers (and the possible need to filter because of any of such an
   extension header content).
   
   The same argument could be made against any
   extension header  that may be desired to be examined at least by
   administrative edge-routers for interdomain policies. Which may 
   include also extension headers not directly targeted as hop-by-hop
   extension headers. So i think this "expensive ACL filtering"
   argument can not serve to single out router-alert without running the
   risk of invalidating the whole IPv6 packet header architecture through
   the back door: This is the cost of business of having an extension
   header architecture.

e) Whether or not there are even any ground to claim there are fast-path processing
   issues is very much in the eye of the vendor and platform. I do observe
   that fast path forwarding planes have gotten more and more
   intelligent and able to perform more processing in the last decade,
   up to the point whee likely any routing/switching < 100 Gbps is performed
   by FPE comparable to general purpose CPU (if not actually being general
   purpose CPU).  And anything faster than 100Gbps can IMHO easily
   perform router-alert processing including filtering unless it is
   legacy hardware.

   For example, draft-han-6man-in-band-signaling-for-transport-qos did
   describe in 2018 a proposal for in-band header processing much
   more complex than router-alert filtering (to make the application easier
   than it is with RSVP/router-alert), and its PoC was implemented 
   in > 100Gbps dedicated metro-ethernet scale programmable vendor ASIC FPE
   which at that time was probably already a few years old. Aka: Instead
   of punting those hop-by-hop inspected packets, the functional
   processing of the header elements is done in the FPE (fast-path)
   itself. Think about it as RSVP in the fast-path. Similarily
   advanced high-touch packet processing features have existed for a
   decade or more in other functional areas in routers,
   such as DPI including telemetric monitoring and statistics gathering
   of gigabits  of video traffic (in the main FPE, not referring to dedicated 
   firewall FPE modules).

   Aka: I do not buy the "expensive ACL filtering" argument as a forward
   looking network/platform design criteria.
 
In summary: I do not think there is good evidence provided to justify
deprectation of router alert, and i am really worried that a deprecation
would take away the only core tool we have today to better orchestrate 
intelligent on-path functionality.

Having said this: I have severe quarrels with router-alert especially how its
specified and implemented, but to me, the only thing that could and should
deprecate router-alert is for it to be superceeded by a better on-path
orchestration extension header.

NIT:
   "The control plane inspects these messages and returns them to the forwarding plane
   so that they can continue on to their ultimate destination".

   This probably needs to be rewritten. MLD for example is a single-hop
   protocol and packets are never re-injected. Whether or not one can
   even call the process in RSVP or PGM re-inject or consume and re-create
   is another question. Not sure if/how any IPv6 bible RFC describes it...

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 5 Jan 2022 23:40:41 +0000

Barry or Michelle😊

Per RFC8126, IANA defines in section 9.6, "obsolete" (no longer in use) and "deprecated" (use is not recommended). So I would lean to "deprecate". As Ron's IANA section is requesting to change the Destination Options and Hop-by-Hop Options Registry, I think that RFC2711 is applicable for update as it is the one listed by IANA, but nothing preventing adding multiple other documents in the string.

(and whatever propose - I'm sure it will be discussed again by the IESG - two very popular discussion items with many views: "deprecate" and "update")
Deborah

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Adrian Farrel
Sent: Sunday, January 2, 2022 4:04 PM
To: 'Brian E Carpenter' <[email-masked]>; '6MAN' <[email-masked]>; [email-masked]
Subject: RE: Thoughts on draft-bonica-6man-deprecate-router-alert

Hi Brian,

Precisely not!

Best,
Adrian

On 03-Jan-22 07:28, Adrian Farrel wrote:
> https://urldefense.com/v3/__https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml*ipv6-__;Iw!!BhdT!yoEZ8-xl8tOuhqG00ndv-RQk9mwVgsftQGiBwgaUb-mC3boiZLzfeD7Qth9DsJs$ 
> https://urldefense.com/v3/__https://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-va__;!!BhdT!yoEZ8-xl8tOuhqG00ndv-RQk9mwVgsftQGiBwgaUb-mC3boiZLzfeD7QsKtN5aw$ 
> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!BhdT!yoEZ8-xl8tOuhqG00ndv-RQk9mwVgsftQGiBwgaUb-mC3boiZLzfeD7Qkm-rOnU$ 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!BhdT!yoEZ8-xl8tOuhqG00ndv-RQk9mwVgsftQGiBwgaUb-mC3boiZLzfeD7Qkm-rOnU$ 
--------------------------------------------------------------------