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 B99A0C14F6F4; Wed, 12 Jun 2024 07:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.105 X-Spam-Level: X-Spam-Status: No, score=-7.105 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_BLOCKED=0.001, 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 AS584Auici5l; Wed, 12 Jun 2024 07:34:51 -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 523A8C14F5ED; Wed, 12 Jun 2024 07:34:47 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta5.iomartmail.com (8.14.7/8.14.7) with ESMTP id 45CEYahI006158; Wed, 12 Jun 2024 15:34:36 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6791C46050; Wed, 12 Jun 2024 15:34:35 +0100 (BST) Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 473FF4604C; Wed, 12 Jun 2024 15:34:35 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS; Wed, 12 Jun 2024 15:34:35 +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 45CEYY0k024195 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Jun 2024 15:34:35 +0100 From: "Adrian Farrel" To: "'Ron Bonica'" , "'Brian E Carpenter'" , "'Ole Troan'" , "'6man WG'" References: <58364a98-cb84-48f0-8e7e-7b1064d48ac2@gmail.com> <034a01dabc47$90273740$b075a5c0$@olddog.co.uk> In-Reply-To: Date: Wed, 12 Jun 2024 15:34:34 +0100 Organization: Old Dog Consulting Message-ID: <03c201dabcd5$a56c8720$f0459560$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03C3_01DABCDE.0731D980" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKlV04t4g6mgp6RmbW3+AiOYxCKmwIrzG9UAf+W9PMCk+j/dQHOaP6iAZi3G36v3cX2EA== 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:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=20221128; bh=dy4taF4EKy35MG94Kn1nQ 30I4SndX/onetG2dIU3usU=; b=j5BaDkzCaW9Dj1oRWYbcdPS42yHP/Y8Kg8atM CfQIEv7c+bK1HvtRP64HTU5V88sOz56eJqrWt2PDVsHswZpb7g1GKWtMwQxTxLeA JMlovRNQxfo9ls23ZLBIyN0YAUCK7id5hA0w0bYAhz7I/BfSpxmTDCFQTfAyfPky H+6X4EQzIBssZOjiB+tm5/+F8zL5KPUDSmIYIIyi32Nl0oMlZVvx2YHb3okyV50P fnhrbvzkttY1fTOrMa1BhJseA7257sDZ5ehfgf31Gqo/inC9a9if7sHxjqXAtLTE qcPwJBWWmo/IDzBzgTSSeqlANXTfKxsOS52EIYhVlPDU6Fekg== 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--26.474-10.0-31-10 X-imss-scan-details: No--26.474-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-28352.003 X-TMASE-Result: 10--26.474500-10.000000 X-TMASE-MatchedRID: jFqw+1pFnMzxIbpQ8BhdbLi7edL7cQQOEQHduga0jMIxN7CM2Nlzz1IM poOsTo0DKNvjpNt9c/U2VMpBLr4i8GtU7eMET1WtjrVn4cme+w5NGNZ5KF1S+N7p0Ru8jKvFN70 WW3nfiNTUhy9D4UF8HBgY0ztehnm8xKLCt/KQhmXmnV13DpXhG67YaZ2V2aJQwr6OgzsUYhqtZC YATy7CACtT5vvZQKSNCUWFRzsRSQL65xr2Tve/pTKVTrGMDe/DWfgivgcUPZN8vx8dQICa6xFug jsZjbgdg4BSUQlYa3QYjxz3bv3t5Q3mZXbns8PVLGQFtelDl4vfuNwtNj3IRKMQi364g884zw5q WkMkRCVtGoGPuIUwaVE86H2xYcJgvNOynLtydfUNmz8qCap2S1HewY36PuY0P3+ELBaPu+9NTSd jDfpz5AP6HuDcBX9qiSGu8ftL8livd9CcO7PpZDmUTEAdaz7PFqnmaWfX3POcVtYw/GEBeuMbuV zdyYYaBEleHrOyiTdIZuLcxU6s7kRfCdMIZ+bd/Sl5cYQQGW8O8pJojG7qSlcbfIj2Ta9sKlgCa sXEiGKqH12uH+NHwkIY7Nm47c28PaUVvydDmM1kGI+vgRTxMFGk5uRH0MzCR6RHdVK85hXaOBWa EqUPGKofXa4f40fC+9mLCCr11/v9owo8VGPvEiI9MxSOQ6CSwl3hycCXE/auMXu+rtfqiCXLNMw xp+cYtEKwVHogdvud4kMXmBB5cbuADNYt2hb2L4+sB3yBsclVx1Cg15eisOT32ZpEASKyNGJ/sl Ktg6pK5KC+dMKXGKZQmkUjwMlNOHOT3z1mU7ZjE3jALg6pYH0tCKdnhB58r10pknZXGJqy5/tFZ u9S3ILalXsF4w7WU6baA36eiawgbhiVsIMQKxZ5+8y352uC X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 Message-ID-Hash: JCMF4644UFWTAQFBIPKX6KZEW6ODOLIP X-Message-ID-Hash: JCMF4644UFWTAQFBIPKX6KZEW6ODOLIP 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 CC: '6man Chairs' <6man-chairs@ietf.org>, draft-bonica-6man-deprecate-router-alert@ietf.org 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_03C3_01DABCDE.0731D980 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 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 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: -------------------------------------------------------------------- ------=_NextPart_000_03C3_01DABCDE.0731D980 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

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.com>; 'Ole Troan' = <otroan@employees.org>; '6man WG' <ipv6@ietf.org>; = adrian@olddog.co.uk
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

 

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

------=_NextPart_000_03C3_01DABCDE.0731D980--