[Sidrops] draft-ietf-sidrops-8210bis flag bits

Randy Bush <randy@psg.com> Mon, 02 May 2022 21:20 UTC

Return-Path: <randy@psg.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C431C15E41C for <sidrops@ietfa.amsl.com>; Mon, 2 May 2022 14:20:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 W4GJ23qF7sfh for <sidrops@ietfa.amsl.com>; Mon, 2 May 2022 14:20:18 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F56C15E412 for <sidrops@ietf.org>; Mon, 2 May 2022 14:20:11 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.93) (envelope-from <randy@psg.com>) id 1nldSi-000kMf-HZ; Mon, 02 May 2022 21:20:08 +0000
Date: Mon, 02 May 2022 14:20:07 -0700
Message-ID: <m2wnf3r5rs.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: SIDR Operations WG <sidrops@ietf.org>
Cc: Warren Kumari <warren@kumari.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/CCaQagcWVaEd-qkyjKgXfJ0iDjA>
Subject: [Sidrops] draft-ietf-sidrops-8210bis flag bits
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 May 2022 21:20:19 -0000

[ as this changes semantics, it really could use constructive comment
  from the wg ]
  
[ excuse length of message, but i dragged the refs in so folk do not
  need to dumsper dive. ]

as mohamed boucadair's routing directorate review pointed out, 8210bis
made some ill advised changes.  the most egregious being changing the
Flags field, see ยง5.1.  "Fields of a PDU"

in 6810/8210 it used to be

   Flags:  The lowest-order bit of the Flags field is 1 for an
      announcement and 0 for a withdrawal.  For a Prefix PDU (IPv4 or
      IPv6), the flag indicates whether this PDU announces a new right
      to announce the prefix or withdraws a previously announced right;
      a withdraw effectively deletes one previously announced Prefix PDU
      with the exact same Prefix, Length, Max-Len, and Autonomous System
      Number (ASN).  Similarly, for a Router Key PDU, the flag indicates
      whether this PDU announces a new Router Key or deletes one
      previously announced Router Key PDU with the exact same AS Number,
      subjectKeyIdentifier, and subjectPublicKeyInfo.

      The remaining bits in the Flags field are reserved for future use.
      In protocol version 1, they MUST be zero on transmission and MUST
      be ignored on receipt.

8210bis says

   Flags:  The lowest-order bit of the Flags field is 0 for IPv4 and 1
      for IPv6.

      The next lowest bit is 1 for an announcement and 0 for a
      withdrawal.  For a Prefix PDU (IPv4 or IPv6), the announce/
      withdraw flag indicates whether this PDU announces a new right to
      announce the prefix or withdraws a previously announced right; a
      withdraw effectively deletes one previously announced Prefix PDU
      with the exact same Prefix, Length, Max-Len, and Autonomous System
      Number (ASN).

it's the addition of the ASPA PDU and trying to avoid two ASPAs, one v4
and one v6, which caused the addition of the AFI bit to the flags field,
and it is only actually used in ASPA

    Bit     Bit Name
    ----    -------------------
     0      AFI (IPv4 == 0, IPv6 == 1)
     1	    Announce == 1, Delete == 0
     2-7    Reserved, must be zero

6810 and 8210 expect bit 0 to be with/ann, not afi

as a bonus, with this change, one could have an IPv4 PDU with the flag
set to IPv6, which is disgusting.

i suggest reverting Flags to
  bit 0 - 0/with 1/ann
  bit 1-7 reserved
and adding an AFI bit to the ASPA

so the ASPA PDU would change from

0          8          16         24        31
.-------------------------------------------.
| Protocol |   PDU    |                     |
| Version  |   Type   |        zero         |
|    2     |    11    |                     |
+-------------------------------------------+
|                                           |
|                 Length                    |
|                                           |
+-------------------------------------------+
|          |          |                     |
|  Flags   |   zero   |  Provider AS Count  |
|          |          |                     |
+-------------------------------------------+
|                                           |
|    Customer Autonomous System Number      |
|                                           |
+-------------------------------------------+
|                                           |
|    Provider Autonomous System Numbers     |
|                                           |
~-------------------------------------------~

to

0          8          16         24        31
.-------------------------------------------.
| Protocol |   PDU    |                     |
| Version  |   Type   |        zero         |
|    2     |    11    |                     |
+-------------------------------------------+
|                                           |
|                 Length                    |
|                                           |
+-------------------------------------------+
|          |          |                     |
|  Flags   | AFI Flag |  Provider AS Count  |
|          |          |                     |
+-------------------------------------------+
|                                           |
|    Customer Autonomous System Number      |
|                                           |
+-------------------------------------------+
|                                           |
|    Provider Autonomous System Numbers     |
|                                           |
~-------------------------------------------~

alternatively, we could have an ASPA4 and ASPA6.  parallel construction
is nice.  but the actual PDUs would be *identical* except for the PDU
Type.

randy