Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA63C1E7249 for ; Wed, 12 Jun 2024 08:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.106 X-Spam-Level: X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=olddog.co.uk Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBCP14Pwn9uf for ; Wed, 12 Jun 2024 08:22:49 -0700 (PDT) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1256DC09E1D0 for ; Wed, 12 Jun 2024 08:22:41 -0700 (PDT) Received: from vs4.iomartmail.com (vs4.iomartmail.com [10.12.10.122]) by mta5.iomartmail.com (8.14.7/8.14.7) with ESMTP id 45CFMcXB007458; Wed, 12 Jun 2024 16:22:38 +0100 Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E3D3E4604A; Wed, 12 Jun 2024 16:22:37 +0100 (BST) Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C4C1746043; Wed, 12 Jun 2024 16:22:37 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs4.iomartmail.com (Postfix) with ESMTPS; Wed, 12 Jun 2024 16:22:37 +0100 (BST) Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk [82.69.109.75]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.7/8.14.7) with ESMTP id 45CFMbiL015945 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Jun 2024 16:22:37 +0100 From: "Adrian Farrel" To: "'Alexandre Petrescu'" , References: <58364a98-cb84-48f0-8e7e-7b1064d48ac2@gmail.com> <034a01dabc47$90273740$b075a5c0$@olddog.co.uk> <03c201dabcd5$a56c8720$f0459560$@olddog.co.uk> <6baef58a-5458-4be2-818d-5dd13d11a2f1@gmail.com> In-Reply-To: <6baef58a-5458-4be2-818d-5dd13d11a2f1@gmail.com> Date: Wed, 12 Jun 2024 16:22:35 +0100 Organization: Old Dog Consulting Message-ID: <03f701dabcdc$5ae931b0$10bb9510$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03F8_01DABCE4.BCAE8410" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKlV04t4g6mgp6RmbW3+AiOYxCKmwIrzG9UAf+W9PMCk+j/dQHOaP6iAZi3G34By8ju0wJsH3Btr7wVk+A= Content-Language: en-gb X-Originating-IP: 82.69.109.75 X-Thinkmail-Auth: adrian@olddog.co.uk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=20221128; bh=CXE73lJGRSAsuCzE5n1WH eQE4BYG0Vjc39q1HmBMMxs=; b=qhXJhYZWsMdekr4wMxoXvz3XL0wa3nZNE3KvN 1apNTrXRKboZLFFL3VlQCZnUYfkpf4BqLif7lNxkjCoDi7DcAbg7d50UBsrVO2YN o3nPj6aghgQpXXBmKhbrWDNd7aT+xVK8S3vU+sAwLocbmsGr+i8E0YMup+f6MhM4 91OLUt7rifcAnBd5vJRSGuhhJujnZCzLXW4hXcuR48eEkMzt9fC377yrZHZ4Y891 9V3z4i6+7smg2DFmkIfrB1r9fNW+lkDWDWLwqlWNYd7G0h1N8qalt8mvKa/8jq5M KNLH5GvEfj6pamUhFZ3ifOs1YygBj9q9/I+9Hy62jOiaB72ig== X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-28352.003 X-TM-AS-Result: No--27.563-10.0-31-10 X-imss-scan-details: No--27.563-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-28352.003 X-TMASE-Result: 10--27.562900-10.000000 X-TMASE-MatchedRID: 8HTFlOrbAtHxIbpQ8BhdbBqkhv3OdF4DNUSduuqYHDuvY1zctlJ9TNLu X2hj/M7Umt59lr1z+lC1V2/fZkKeW2Evtl6WZ5l19dFc7Qbe8mopA2ExuipmWj7OtqsP0tMLQbN TsIpfWx3Id/bnc+VEhfnwc/pPl6z+7DQeAa/IxAXmu6GrtSORD5GAt645FF0SbPhxQ+wdmOmjk6 a2d9MKSNSHL0PhQXwcGBjTO16GebzEosK38pCGZeadXXcOleEbrthpnZXZolDCvo6DOxRiGq1kJ gBPLsIAK1Pm+9lApI0JRYVHOxFJAvrnGvZO97+lMpVOsYwN78NZ+CK+BxQ9k3y/Hx1AgJrrEW6C OxmNuB2DgFJRCVhrdBiPHPdu/e3lDeZlduezw9UsZAW16UOXi9+43C02PchEoxCLfriDzzjPDmp aQyREJW0agY+4hTBpUTzofbFhwmC807Kcu3J19Q2bPyoJqnZLUd7Bjfo+5jQ/f4QsFo+7701NJ2 MN+nPkIx/OqCk5J13oLcJM7jLy2fLiDzoQGx5HnbAFQtf6BpzT2VrdfuNrJrXl40gTGJ5pXmttk 0Jk5FKAwG2maXQMIEmlX2scVfePszCdMqCRuw7BtFDYGmaWKjeXamXCCu1Ya22EBxsetkvCUcSg 1GQtKLw2w11c+1o/N4bvLJyYej6VhMNxvKs1PMx+nfdJm+PijlRp8uau9oYj0vSXSt1uP7QICuE 7V6z94CY7pOSMb6UUvJuNM8UQsa+OY4N4S2liIj0zFI5DoJLCXeHJwJcT9q4xe76u1+qIJcs0zD Gn5xi0QrBUeiB2+53iQxeYEHlxu4AM1i3aFvaeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyLr8uVzX avvg4QViJlGwPJ1lExlQIQeRG0= X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 Message-ID-Hash: 5CXSQP6GVKPNJ3D5DANNCKAMOCIMHQYL X-Message-ID-Hash: 5CXSQP6GVKPNJ3D5DANNCKAMOCIMHQYL X-MailFrom: adrian@olddog.co.uk X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ipv6.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc4 Precedence: list Reply-To: adrian@olddog.co.uk Subject: =?utf-8?q?=5BIPv6=5DRe=3A_Adoption_call_for_draft-bonica-6man-deprecate-rout?= =?utf-8?q?er-alert?= List-Id: "IPv6 Maintenance Working Group (6man)" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_03F8_01DABCE4.BCAE8410 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Although some might argue that I should have been institutionalised. =20 From: Alexandre Petrescu =20 Sent: 12 June 2024 15:43 To: ipv6@ietf.org Subject: [IPv6]Re: Adoption call for = draft-bonica-6man-deprecate-router-alert =20 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 =C3=A0 16:34, Adrian Farrel a =C3=A9crit : 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. =20 But that=E2=80=99s a long way from being able to claim =E2=80=9Cmost = implementations=E2=80=9D. =20 Time for a survey? =20 A =20 From: Ron Bonica =20 Sent: 12 June 2024 15:21 To: 'Brian E Carpenter' = ; 'Ole Troan' = ; '6man WG' = ; adrian@olddog.co.uk = =20 Cc: '6man Chairs' <6man-chairs@ietf.org>; = draft-bonica-6man-deprecate-router-alert@ietf.org = =20 Subject: Re: [IPv6]Re: Adoption call for = draft-bonica-6man-deprecate-router-alert =20 Adrian, =20 Thanks for this excellent history. Your institutional memory is, as = usual, amazing. =20 Am I right in saying that today, most RSVP-TE implementations do = not=E2=80=8B use the IPv4 Router Alert by default? =20 = Ron =20 P.S.: I remember many of the RFCs that you cite. But I was a mere lad = in those days =F0=9F=98=89 =20 =20 =20 Juniper Business Use Only _____ =20 From: Adrian Farrel > Sent: Tuesday, June 11, 2024 5:37 PM To: 'Brian E Carpenter' >; Ron Bonica >; 'Ole Troan' >; '6man WG' > Cc: '6man Chairs' <6man-chairs@ietf.org >; = draft-bonica-6man-deprecate-router-alert@ietf.org = = > Subject: RE: [IPv6]Re: Adoption call for = draft-bonica-6man-deprecate-router-alert=20 =20 [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 > Sent: 11 June 2024 21:25 To: Ron Bonica >; Ole = Troan >; 6man WG = > Cc: 6man Chairs <6man-chairs@ietf.org >; = draft-bonica-6man-deprecate-router-alert@ietf.org = =20 Subject: [IPv6]Re: Adoption call for = draft-bonica-6man-deprecate-router-alert Ron, For my education: > - new work. What if there is a new protocol requiring a punt out of = the forwarding path by an intermediate router? Isn=E2=80=99t HBH + = Router Alert the easiest and most performant way for the forwarding = plane to do that? Alternatively we=E2=80=99ll 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 ipv6@ietf.org =20 Administrative Requests: -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org =20 Administrative Requests: -------------------------------------------------------------------- ------=_NextPart_000_03F8_01DABCE4.BCAE8410 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Although some might argue that I = should have been institutionalised.

 

From: Alexandre Petrescu = <alexandre.petrescu@gmail.com>
Sent: 12 June 2024 = 15:43
To: ipv6@ietf.org
Subject: [IPv6]Re: Adoption = call for = draft-bonica-6man-deprecate-router-alert

 

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 = =C3=A0 16:34, Adrian Farrel a = =C3=A9crit :

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=E2=80=99s a long way from being able to claim =E2=80=9Cmost = implementations=E2=80=9D.

 

Time for a = survey?

 

A

 

From: Ron Bonica <rbonica@juniper.net> =
Sent: 12 June 2024 15:21
To: 'Brian E Carpenter' <brian.e.carpenter@gmail.c= om>; 'Ole Troan' <otroan@employees.org>; = '6man WG' <ipv6@ietf.org>; adrian@olddog.co.uk
Cc:= '6man Chairs' <6man-chairs@ietf.org>; = draft-b= onica-6man-deprecate-router-alert@ietf.org
Subject: Re: = [IPv6]Re: Adoption call for = draft-bonica-6man-deprecate-router-alert

 

Adrian,<= /o:p>

 

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=E2=80=8B 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 <adrian@olddog.co.uk>
Sen= t: Tuesday, June 11, 2024 5:37 PM
To: 'Brian E Carpenter' = <brian.e.carpenter@gmail.com>; Ron Bonica <rbonica@juniper.net>; 'Ole = Troan' <otroan@employees.org>; '6man = WG' <ipv6@ietf.org>
Cc: '6man = Chairs' <6man-chairs@ietf.org>; draft-b= onica-6man-deprecate-router-alert@ietf.org <draft-b= onica-6man-deprecate-router-alert@ietf.org>
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
           &= nbsp;  the node must be diverted to the RSVP program = for
           =    processing, without being forwarded.  The RSVP = messages = to
           &= nbsp;  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:

          &= nbsp;   RSVP must be able to cause Path, PathTear, and = ResvConf
          &= nbsp;   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 <brian.e.carpenter@gmail.com>
Sent: 11 June 2024 21:25
To: Ron Bonica <rbonica@juniper.net>; Ole = Troan <otroan@employees.org>; 6man = WG <ipv6@ietf.org>
Cc: = 6man Chairs <6man-chairs@ietf.org>; draft-b= onica-6man-deprecate-router-alert@ietf.org
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=E2=80=99t HBH + Router Alert the easiest and = most performant way for the forwarding plane to do that? Alternatively = we=E2=80=99ll 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
ipv6@ietf.org
Administrative = Requests:
------------------------------------------------------------= --------



---------------------------=
-----------------------------------------
IETF IPv6 =
working group mailing list
ipv6@ietf.org
Admi=
nistrative =
Requests:
------------------------------------------=
--------------------------
------=_NextPart_000_03F8_01DABCE4.BCAE8410--