Re: [IPv6] New Version Notification for draft-bonica-6man-deprecate-router-alert-01.txt

[Toerless Eckert <[e-mail]>]

On Wed, Feb 14, 2024 at 04:23:00PM +0000, Ron Bonica wrote:
> Toerless,
> 
> The base RSVP specification allows use of either the router alert or direct addressing.

Re-reading rfc2205 i can not find this to be true. "3.11.4 RSVP/Routing Interface" specifically
does not not demand or describe that RSVP must be able to determine the next-hop upstream
neighbor in the "Route Query" section. Only the next-hop interface.

> Early in the history of RSVP-TE, vendors agreed to use direct addressing and avoid the router alert. No RFC documents this agreement. It is just inherited wisdom.

You (MPLS community) should really make yourself honest and figure out where to
best document this. I would propose we craft a small paragraph outlining this
change from the RFC2205 spec and propose it as an rfc3209 Errata with target
"waiting for document update". Aka: could move into any future RFC where
it would make sense to attach "updates rfc3209" to it, or else it just stays
an Errata. One could think of an equivalent errata for rfc2205 pointing to
the rfc3209 errata as an example for the premise that router alert SHUOLD
be replaced for applications that MUST be deployed with full and strict hop-by-hop support
of RSVP.

We could write a short RFC that does this update to RFC3209/RFC2205, but
given how it would have to discuss extending/modifying rfc2205/3.11.4, i fear
we'd end up in TSVWG where nobody wants to remember RSVP ;-))


But back to the purpose of this discuss: I think the RSVP-TE case is irrelevant
as an argument to deprecate router-alert, because if we assume that RSVP-TE
MUST always be hop-by-hop, then router-alert is misplaced there anyhow. It really
only makes sense to use it, when you reasonably can not solve the problem with
explicit addressing. But that does not imply that router-alert is misplaced for
any other uses of RSVP.

The use of router-alert is to help solve the otherwise fairly
difficult and most applications arguably impossible task to solve auto-discovery
of the next node on a path supporting a particular feature (when it's not mandatory the next-hop).
The discovery of a hop that's not the next-hop is the most obvious case, but
when i was architecting that stuff, i also ran into problems even when there
was hop-by-hop RSVP support. Namely in IP networks, the next-hop selection
can be extremely difficult:

- There is no standard AFAIK in general for determining the ECMP next-hop
  (tell me if that's not true in MPLS). Every router does its own
  ECMP algo, and many even have configurable options.

- There may be even more complex routing than ECMP, such as policy routing.

Different vendors have done AFAIK different degrees of RSVP contrl plane being
able to deal with different subsets of being able for RSVP to correctly determine
the right next-hop in the presence of these various features. And given how
RSVP-TE by itself is a way to take out all the complexities of advanced
traffic steering from the routing underlay it is an ideal candidate for
a simple routing underlauy where this is no problem for the next-hop
(not sure about the ECMP part though..).

> Your reference to DETNET confuses me. I am by no means a DETNET expert, but I don't think that DETNET uses the Router Alert Option today. Does it?

For DetNet with MPLS forwarding plane we should be fine to use RSVP-TE as-is wrt. non-use of router-alert.

For DetNet with IP forwarding plane  or others there are a couple more issues to resolve, maybe lets take it offline.

> Let me try to restate your question in a more abstract way. You can tell me if I have understood the question correctly.
> 
> Node A sends packets to Node Z. These packets traverse Nodes B, C, D, etc. Nodes A and Z participate in a protocol. Some, but not all of the nodes along the path also participate in the protocol. You want the packet to reach the control plane on nodes that participate in the protocol. But you don't want the packet to disturb the control plane on nodes that do not participate in the protocol.
>
> Node A doesn't know which nodes the packet will traverse. Nor does Node A know which nodes on the path participate in the protocol.
> 
> How do we get the packet to the control plane on the nodes where it should visit the control plane? How do we avoid making the packet disturb the control plane on other nodes?
> 
> Am I understanding the question correctly?

Yes exactly. And router-alert is the answer how to do it. Especially given that
the packet match required to determine whether to punt such a packet is the combination
of both the extension header, but also the protocol field in that extension header.
So a node can punt only the packets for the protocols that it does have running.
Such as RSVP, but not PGM (which is a bit theoretical for IPv6 because there is no IPv6
RFC for PGM, just for IPv4, but it would logically work the same).

Cheers
    Toerless

>                                                           Ron
> 
> 
> 
> 
> Juniper Business Use Only
> 
> ________________________________
> From: Toerless Eckert <[e-mail]>
> Sent: Monday, February 12, 2024 10:15 PM
> To: Ron Bonica <[e-mail]>
> Cc: Ole Troan <[e-mail]>; [e-mail] <[e-mail]>
> Subject: Re: [IPv6] New Version Notification for draft-bonica-6man-deprecate-router-alert-01.txt
> 
> [External Email. Be cautious of content]
> 
> 
> On Thu, Feb 01, 2024 at 09:26:41PM +0000, Ron Bonica wrote:
> > Hi Toerless,
> >
> > In the next version of the draft, I will make a specific statement about MLD future versions.
> >
> > Sadly, RFC 2205 predates RSVP-TE, the only widely deployed RSVP implementation. I don't know which RFC talks about moving away from the Router Alert Option. But I do know that all of the major vendors made this move more than ten years ago.
> 
> Please find that reference, if it exists. I still can not see how this will work in incremental / partial
> deployments where the upstream router is not necessarily an RSVP, but that next RSVP
> router is maybe two hops away.
> 
> > Due to the nature of MPLS, RSVP-TE must be deployed on every node along the LSP. There is no partial deployment.
> 
> [ I would be careful with this notion when considering DetNet where we seem to be including all type of
>   MPLS over IP/UDP type of solutions. And we have not gotten to the most desirable control plane. But i am
>   a bit freaked out by these mix&match options anyhow, just saying ;-)) ]
> 
> So, if for all we have to care for operationally right now, MPLS has never integrated the mechanisms
> for loose/incremental deployment with RSVP-TE, then your statement may be
> correct for RSVP-TE, but it is not correct AFAIK for RSVP for IP.
> 
> And i am fully supportive of "Don't use Router Alert unless you can not come up with a better
> solution", and for strict deployments of course that is easy. But that is completely different from fully deprecating it.
> 
> (for example, i wish we would have integrated router-alert into PIM in the 1990th to enable
>  incremental deployment in enterprises. But we also thought that full/strict deployment was possible.
>  Alas then we had to go to a lot less "full-upgrade-willing" set of communities than what you
>  likely experienced with MPLS (aka: enterprises and the like).
> 
> Cheers
>    Toerless
> 
> >
> > Maybe we can use another protocol as an example.
> >
> >                                                                           Ron
> >
> >
> >
> > Juniper Business Use Only
> >
> > ________________________________
> > From: Toerless Eckert <[e-mail]>
> > Sent: Thursday, February 1, 2024 12:28 PM
> > To: Ron Bonica <[e-mail]>
> > Cc: Ole Troan <[e-mail]>; [e-mail] <[e-mail]>
> > Subject: Re: [IPv6] New Version Notification for draft-bonica-6man-deprecate-router-alert-01.txt
> >
> > [External Email. Be cautious of content]
> >
> >
> > On Thu, Feb 01, 2024 at 05:04:35PM +0000, Ron Bonica wrote:
> > > Typical problem with those statements would be protocols that evolve but need to keep
> > > backward compatibility. Asssume for example, MLDv3 would not want to break backward
> > > compatibility and hence continues to use router-alert. Would it still be allowed under the
> > > rule of your proposed RFC ?
> > >
> > > [RB] Absolutely. MLD is an existing protocol. MLDv3 would be a new version of an existing protocol.
> >
> > Would be good to maybe add a statement about that to the draft. Not that many existing
> > protocols that rely on router alert AFAIK, so maybe even enumerate them.
> >
> > > > Yes, new protocols have an alternative to the Router Alert Option. RSVP offers a relevant case study (albeit and IPv4-based case study).
> > > >
> > > > Early implementations of RSVP used the IPv4 Router Alert Option. Most vendors abandoned that strategy because many operators block all packets containing the IPv4 Router Alert. (How little things have changed!) They migrated to a strategy where the RSVP packet is addressed to the router, and a Router Alert is not required.
> > >
> > > I am not aware of a working solution for this approach in incremental or non-full deployments.
> > >
> > > Aka: The reason for router-alert to be included in RSVP is that the packet is sent along the
> > > path and picked up by the first router supporting RSVP. And ignored by intermediate routers.
> > >
> > > The workaround only works if every hop along the path supports and enables RSVP - because there
> > > is no method to detect a router a few hops away reliably, especially in interdomain or more
> > > complex routing intradomain deployments (traffic engineering etc).
> > >
> > > [RB] We have an existence proof of RSVP working without the Router Alert. The industry has also demonstrated that seamless migration is possible.
> >
> > Can you point me to the RFC where that mechanism is described ?
> > RFC2205 does not have it.
> >
> > > [RB] I think that you have an interesting question, but I don't understand it. Could you describe a hypothetical new protocol that has this problem?
> >
> > Just incremental or partial deployment of such a protocol. E.g. you don't deploy it on
> > all hops, but just those that have (to stick to the RSVP example) relevant resource reservation
> > needs.
> >
> > Cheers
> >     Toerless
> > >
> > > Cheers
> > >     Toerless
> > >
> > > >
> > > >
> > > > Juniper Business Use Only
> > > >
> > > > ________________________________
> > > > From: Ole Troan <otroan=[e-mail]>
> > > > Sent: Wednesday, January 31, 2024 8:07 AM
> > > > To: Ron Bonica <[e-mail]>
> > > > Cc: [e-mail] <[e-mail]>
> > > > Subject: Re: [IPv6] New Version Notification for draft-bonica-6man-deprecate-router-alert-01.txt
> > > >
> > > > [External Email. Be cautious of content]
> > > >
> > > >
> > > > > I let this draft expire two years ago when I became too ill to pursue it. Now, I am happy to report, that I am feeling well enough to annoy you with it again 😉
> > > > >
> > > > > Let the food fight begin!
> > > >
> > > > I don’t think we should deprecate something unless we have a good alternative to solve the problem.
> > > > Given that MLDv2 is a fundamental part of the IPv6 protocol suite.
> > > > Have you thought about how MLD should work without the Router Alert option?
> > > >
> > > > O.
> > > >
> > > > >
> > > > > Juniper Business Use Only
> > > > > From: [e-mail] <[e-mail]>
> > > > > Sent: Wednesday, January 31, 2024 7:51 AM
> > > > > To: Ron Bonica <[e-mail]>
> > > > > Subject: New Version Notification for draft-bonica-6man-deprecate-router-alert-01.txt
> > > > >  [External Email. Be cautious of content]
> > > > >
> > > > >
> > > > > A new version of Internet-Draft
> > > > > draft-bonica-6man-deprecate-router-alert-01.txt has been successfully
> > > > > submitted by Ron Bonica and posted to the
> > > > > IETF repository.
> > > > >
> > > > > Name:     draft-bonica-6man-deprecate-router-alert
> > > > > Revision: 01
> > > > > Title:    Deprecation Of The IPv6 Router Alert Option
> > > > > Date:     2024-01-31
> > > > > Group:    Individual Submission
> > > > > Pages:    8
> > > > > URL:      https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-bonica-6man-deprecate-router-alert-01.txt__;!!NEt6yMaO-gk!Cwq66zb-C2k1NU93EXgMcuesx6u1_281vcN-JGNC3fdtm26405LpuNHWP079H8qnucFNqG98EJdr-0jRAHA7loJHZk2IdEY$
> > > > > Status:   https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-6man-deprecate-router-alert/__;!!NEt6yMaO-gk!Cwq66zb-C2k1NU93EXgMcuesx6u1_281vcN-JGNC3fdtm26405LpuNHWP079H8qnucFNqG98EJdr-0jRAHA7loJHPvfO9fA$
> > > > > HTMLized: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-bonica-6man-deprecate-router-alert__;!!NEt6yMaO-gk!Cwq66zb-C2k1NU93EXgMcuesx6u1_281vcN-JGNC3fdtm26405LpuNHWP079H8qnucFNqG98EJdr-0jRAHA7loJHQZlElYI$
> > > > > Diff:     https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-bonica-6man-deprecate-router-alert-01__;!!NEt6yMaO-gk!Cwq66zb-C2k1NU93EXgMcuesx6u1_281vcN-JGNC3fdtm26405LpuNHWP079H8qnucFNqG98EJdr-0jRAHA7loJHrefpBfo$
> > > > >
> > > > > Abstract:
> > > > >
> > > > >    This document deprecates the IPv6 Router Alert Option.  Protocols
> > > > >    that use the Router Alert Option may continue to do so.  However,
> > > > >    protocols standardized in the future must not use the Router Alert
> > > > >    Option.
> > > > >
> > > > >
> > > > >
> > > > > The IETF Secretariat
> > > > >
> > > > >
> > > > > --------------------------------------------------------------------
> > > > > IETF IPv6 working group mailing list
> > > > > [e-mail]
> > > > > Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Cwq66zb-C2k1NU93EXgMcuesx6u1_281vcN-JGNC3fdtm26405LpuNHWP079H8qnucFNqG98EJdr-0jRAHA7loJHUVRj0nM$
> > > > > --------------------------------------------------------------------
> > > >
> > > >
> > > >
> > >
> > > > --------------------------------------------------------------------
> > > > IETF IPv6 working group mailing list
> > > > [e-mail]
> > > > Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!G2XQM1YGEbM8WxHJ8I4xgWlv9iLcy_cCL6zm1s4fjIRZ_2mmmawobJT8c8wezhw_VeDlh0YCepIr$
> > > > --------------------------------------------------------------------
> > >
> > >
> > > --
> > > ---
> > > [e-mail]
> >
> > --
> > ---
> > [e-mail]
> 
> --
> ---
> [e-mail]

-- 
---
[e-mail]