Re: [spring] CSID proposed clarifications

Andrew Alston <Andrew.Alston@liquid.tech> Thu, 14 October 2021 14:34 UTC

Return-Path: <andrew.alston@liquid.tech>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867DA3A09EC for <spring@ietfa.amsl.com>; Thu, 14 Oct 2021 07:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.854
X-Spam-Level:
X-Spam-Status: No, score=-0.854 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, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=liquid.tech
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhnvghTWYzhd for <spring@ietfa.amsl.com>; Thu, 14 Oct 2021 07:34:02 -0700 (PDT)
Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [185.58.86.182]) (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 7677C3A08F9 for <spring@ietf.org>; Thu, 14 Oct 2021 07:34:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquid.tech; s=mimecast20210406; t=1634222038; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=d2xkoaDHKwUIh+kyo7NivtZROvm/qVs2UcXHeAQcMxQ=; b=eqGQm86iFnWiLAkFWbwYiWHjIUVV8k3DCFQC01EV6xJEWCEXIZ/NtOLd/MeeYf0iZu7eAA P24+O/DsDUfXcX796/wsAMWxkKyevwUQ1B5MCTsdB7YDr3aepGoX3oH7yzSssiIysD95P5 uAVqolLT/PS0P1UuhyvxjtO3unQ3NiE=
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp2054.outbound.protection.outlook.com [104.47.9.54]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-147-8JK7CYPROeqT5hRnAVmjKg-1; Thu, 14 Oct 2021 15:33:54 +0100
X-MC-Unique: 8JK7CYPROeqT5hRnAVmjKg-1
Received: from AS8PR03MB7622.eurprd03.prod.outlook.com (2603:10a6:20b:346::6) by AS8PR03MB7970.eurprd03.prod.outlook.com (2603:10a6:20b:427::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.16; Thu, 14 Oct 2021 14:33:52 +0000
Received: from AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9]) by AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9%7]) with mapi id 15.20.4608.016; Thu, 14 Oct 2021 14:33:52 +0000
From: Andrew Alston <Andrew.Alston@liquid.tech>
To: "Darren Dukes (ddukes)" <ddukes=40cisco.com@dmarc.ietf.org>, SPRING WG <spring@ietf.org>
Thread-Topic: CSID proposed clarifications
Thread-Index: AQHXwPmD76WD43ON70uWpO9ECDy+ZqvSjuoA
Date: Thu, 14 Oct 2021 14:33:52 +0000
Message-ID: <AS8PR03MB7622B60021ECF2ABA7A5E20EEEB89@AS8PR03MB7622.eurprd03.prod.outlook.com>
References: <BN6PR11MB40815FF94A9509B46469A4F4C8B89@BN6PR11MB4081.namprd11.prod.outlook.com>
In-Reply-To: <BN6PR11MB40815FF94A9509B46469A4F4C8B89@BN6PR11MB4081.namprd11.prod.outlook.com>
Accept-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1580b034-bd5c-456f-e08d-08d98f1fa50c
x-ms-traffictypediagnostic: AS8PR03MB7970:
x-microsoft-antispam-prvs: <AS8PR03MB797091E42F24E9CCAE7196B0ECB89@AS8PR03MB7970.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0
x-microsoft-antispam-message-info: FQ5Pz5Gkxm5WXQibL8+nXLwpT1aJm1Rt99NB1SXzBw43mor/UFQUZVxnOXWlMpcawC0m5lZIl5yVOMRYORNz9dZI4+FbIskvHHJfFd+wGgKOlbwGLYn/fUMI72MYfNJidNdXsPBn7MU301amliTZgmKk5VEzCYNFz00Wj9wFUpEavQ+aLD38qmeA5LMOzogone2MDKUydcpwXtch4NPSLdGtdACI39gO8lxpmafqcVj2FzV5BiDPhJs3mr3KEIjKu5CveSIfVDQhuiLWiDDLcYGJT0g9f8lRcKshon4of0LSc7wMpnFToh1YaKRPh5jI5V9OTYr7eahe4ERRjC5hJysaufeXWvM5xYikpWWgmZioBa9cT4TZlCChblH42+1Bcm4Pfgv8w3z1znkex7g2HPdDJPbLCTXi0ss29Z0dDcWzaPfzCDO7jvFA6fNhijJMjI9W9jK3Ek2rdAXMC1gjSms9HG2mKzZ1u4wHl9ge3eXkq8fTv/egAF5FwLo9V+Piedlf9Am2bKfVba6KWoi/Kgkbk/wn3VdkQYQDjQRhmUb8vKXfnV6ZyexmMB8i3WLL1tOg6uOJXeB1NblUnkAOlxpGc2XNPqMnukphbVbMK+3Z9/kk8hA/e71jB//waOMgHdRs6OK2+AG9wIbuHevV323D6HFVFmEEAY8+bEuSP+5Z/Pij0ABUaVB76TqJEL7HbSikSxPnFlQdEWKxlCXeTXxlOV5CSuG2kt5iTw2QCdgnOj43TCdJF8xg4vUejjlq+uZCvWGie+NdVp8ZFJp/sHkiBoFzNbdGeIwtd36/T0QJwl7JJtYumqgZXwEeAx+IbyfOj3CvQZsiW+ZdeZLzxg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR03MB7622.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(64756008)(66946007)(76116006)(66476007)(66556008)(52536014)(66446008)(9686003)(5660300002)(186003)(55016002)(83380400001)(71200400001)(8676002)(2906002)(166002)(8936002)(38070700005)(86362001)(53546011)(110136005)(38100700002)(508600001)(316002)(122000001)(6506007)(7116003)(7696005)(33656002)(3480700007); DIR:OUT; SFP:1102
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 5mIiXGHiCuwnYkaa/GFOuDZxYpt6+Wwc3TrUP1YieCKkFUXZdhdck2O+DsS6lle4kNJIZpEIl2accu3p3Pspx7O8VqYIYLT0T3Z1X4NZ8nCsQEAwIny2yatavk+DUyelFcSupIOEUo3aNAgyNUjyE2E7K/OJHZkanN7JJ4jxHauFvjMi7dMxRPSWYpf9I3fKXpZjpwt2KG1rlIo43s/GEHW6gN788kiUMXs3i9mdNxnQwESux+W15pMGln3+cs3SLjg5mf0eW52yKQ95q9uAhx+GeEIQcmrwS6gYQigYVzV6lfmD2+ciNWGNVkeeUmxeljKfOOWqL8mviWQupE+CknvcyVyVe8K5XJ0rMKQpk3FrLZb7LXYWpPhbkterC5cYm33FPCapmAYrYv51x91rF98X5+KMGGrcbpx8fUxhA5oepPmRAeuN3hqjfO3R+lgFEEzPLnfD1XAlonPDSGAfHWJGXszYgyKYly9vXuAKZ7yBPa358F18UMuk/L3CekXmqC2zDIK+L3DL/NFLUfqr61pEhylbJcXAnJnXnJxaWDDsrZTtJJFGZIxq6u9Y1DmaNlZfuvySCL9DU5IiqfnIbMApY6fy9hvolFzt6mI945luH4NvHZuIHQAZ5CPpPcMWIioiLEYC0RwxYSccWr+bhWJG+YjAaoRD/cO4ka1UfhuL1gGLMeED8vIA0x4ahmF897XR7RbWqDL8/IMdVxvPUnWnkwM8bpURHO9rq6aumsydCFH6wibx4m0btiImaBzGZIv52mMdz/rG/qU8MJnS7y1jovLQ/cczOhEkefysUtvhVvaBq3QUvStmxliBFIWP9a08vmDG72WAwd3p9Tj4BC/xPZHSTqlc/dvkCugUPA1WKzKlTa25oOtXcDaDbt+/ShF8nc6QlGyEAHPO+PuMcRoWoKdVCZbv1QsVnqB3kBS7WaZ0sEhTqfJgsA3MK7N59Ymdd5c5i41ZUyt/IdTEBHuIHXNjHvK4NyFcS7saxnNWnOrOZIrjrcBBNWUbjOv46AqWyWq6s7OwsYbWHCwDSqAKixKzvSOLqvBKJlB/YJmqBfq4SFFYhG4IhGI7hvh6+WoiQcW9KOonQNZUmzEtPcr7NRvHc7fGQ4FVowCt49a6Yfm1xjjofozJIMEF3qensoSvT+gqaJtFMBylqcHQN1R7mnoUjUiSmcfNjOb8WGBiGbt46nHk1v2YHa1r6VJYn0he35qcv5+WIdk2M6W6n0jnXnRrQYs23iJg2fQviKCunW2pb+YgwsnN0Cz+IoBcLCzeH0UVyyDLSRWkTsERFz5hn5JAOV6eFpzjdx8t4hGTFQ2xYmHDRFcTI8GJgEMgp0ZmpOXPd5I7WIwq/EcIv1s5teDG3YOIt2r3NvZ/0PI=
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: liquid.tech
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB7622.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1580b034-bd5c-456f-e08d-08d98f1fa50c
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2021 14:33:52.4234 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: u18ry/SgXXuq7/l2pLegiwBWWwFcBjV7b6EOJ9NbHUvWwkF+1MGNghDvKEusOWti4LBKWVMAeLcXFBi8gvs+f7AGgZV6KUmdO86oxAxv5U4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7970
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquid.tech
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: liquid.tech
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_AS8PR03MB7622B60021ECF2ABA7A5E20EEEB89AS8PR03MB7622eurp_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/Pa3zp6AA39OBQ-59qAf9KUNF5Uc>
X-Mailman-Approved-At: Fri, 15 Oct 2021 01:17:52 -0700
Subject: Re: [spring] CSID proposed clarifications
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Oct 2021 14:34:09 -0000

(Apologies if this appears twice - seems something went screwy with my outbound address so the other version of this is moderated)

Darren,

I'm a little confused here reading this - but all said and done - on the next behavior - how is this different from doing something along the lines of

Da[loc_bits/8] << sid_size

Because - when I trace this all out into actual C code - that's pretty much what it seems to summarize down to - more specifically - it could be done something like this:

(taking out all the comparisons and error checking)

__m128i vec;
__u8 output[16];

vec = __mm_loadl_epi64((void *)da[loc_size/8])
if(sid_size == 16) {
              vec = _mm_bsrli_si128(vec, 2)
} else {
              vec = _mm_bsrli_si128(vec, 4)
}
_mm_store_u_si128((__m128i*)output, vec);
memcpy(da[loc_size/8], output, 16-(loc_size/8));

(think I got that pretty much right)

Andrew


From: spring <spring-bounces@ietf.org> On Behalf Of Darren Dukes (ddukes)
Sent: Thursday, October 14, 2021 3:54 PM
To: SPRING WG <spring@ietf.org>
Subject: [spring] CSID proposed clarifications

The NEXT-C-SID and REPLACE-C-SID flavors are functionally very similar.
In both cases the SID in the IPv6 Destination Address (DA) contains an argument,
that argument is used to construct the next SID from the active segment in
the SRH Segment List.

I believe the following pseudocode is a much better description of their
segment endpoint processing. You'll notice there is no manipulation of
the bits in the IPv6 DA.

I propose we replace the pseudocode in the draft with the following,
stand-alone pseudocode, for the NEXT-C-SID and REPLACE-C-SID flavors
of the END behavior (sections 4.1.1 and 4.2.1 respectively).

Equivalent changes can be completed for the NEXT-C-SID and REPLACE-C-SID
flavors of the END.X behavior (sections 4.1.2 and 4.2.2 respectively) and
NEXT-AND-REPLACE-C-SID flavor.

Comments are appreciated.

Thanks
  Darren

4.1.1.  End with NEXT-C-SID

When processing an IPv6 packet that matches a FIB entry locally
instantiated as an End SID with the NEXT-C-SID flavor, the SRH
processing described in Section 4.1 of [RFC8986] is replaced as
follows.


S.01 When an SRH is processed {
S.02  If (IPv6.DA.Argument == 0 and SRH.SegmentsLeft == 0) {
S.03     Stop processing the SRH, and proceed to process the next
         header in the packet, whose type is identified by
         the Next Header field in the routing header.
S.04  }

S.05  If (IPv6.HopLimit <= 1) {
S.06     Send an ICMP Time Exceeded message to the Source Address
         with Code 0 (Hop limit exceeded in transit),
         interrupt packet processing, and discard the packet.
S.07  }

S.08  # Determine the maximum SRH Last Entry
S.09  Set maxLE to ((SRH.HdrExtLen / 2) - 1)

S.10  Initialize 128-bit buffer memory S to 0.
S.11  Initialize local parameter Argument to the value of IPv6.DA.Argument

S.12  If (Argument == 0) {
S.13    If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)) {
S.14      Send an ICMP Parameter Problem to the Source Address
           with Code 0 (Erroneous header field encountered)
           and Pointer set to the Segments Left field,
           interrupt packet processing, and discard the packet.
S.15    }

S.16    Decrement SRH.SegmentsLeft by 1

S.17    Set S to the value of SRH.SegmentList[SRH.SegmentsLeft]
S.18  }
S.19  Else {
S.20    If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)) {
S.21      Send an ICMP Parameter Problem to the Source Address
          with Code 0 (Erroneous header field encountered)
           and Pointer set to the Segments Left field,
           interrupt packet processing, and discard the packet.
S.22    }

S.23    Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common locator block)

S.24    If (SRH.SegmentsLeft > SRH.LastEntry) {
S.25      Initialize local parameter ActiveSegment to the value of DA
S.26    }
S.27    Else {
S.28      Initialize local parameter ActiveSegment to the value
S.29       of SRH.SegmentList[SRH.SegmentsLeft]
S.30    }

S.31    Initialize local parameter BitLength to (CountTrailingZeros(ActiveSegment) +
                                                  AL - CountTrailingZeros(Argument))
S.32    Initialize local parameter BitIndex to (128 - BitLength)

S.33    Set S[B..B+BitLength-1] to the value of
         ActiveSegment[BitIndex..(BitIndex+BitLength-1)]
S.34  }

S.35  Set IPv6.DA to the value of S

S.36  Decrement IPv6.HopLimit by 1

S.37  Submit the packet to the egress IPv6 FIB lookup for transmission
       to the new destination.
S.38 }

4.1.1.1<http://4.1.1.1> Upper layer header processing

The upper-layer header processing described in Section 4.1.1 of
[RFC8986] is replaced as follows.

S.01  Initialize local parameter Argument to the value of IPv6.DA.Argument
S.02  If (Argument != 0) {
        # In this case, the SRH was not added by source
        # The source compressed it into the active segment in IPv6.DA
        # Build a pseudo header from the active segment in the IPv6.DA for use
      # during processing.
S.03    Initialize a 24-byte local SRH in memory to 0's for use below
S.04    Set SRH.MaxHdrLen to 3
S.05    Set SRH.RoutingType to 4
S.06    Set SRH.SegmentsLeft to 0
S.07    Set SRH.SegmentList[0] to the value of IPv6.DA

S.08    Process the SRH as per section 4.1.1,
S.09     noting such processing is limited to the pseudo SRH
S.10     since Argument is not 0.
S.11  }

S.12  If (Upper-Layer header type is allowed by local configuration) {
S.13    Proceed to process the Upper-Layer header
S.14  } Else {
S.15    Send an ICMP Parameter Problem to the Source Address
         with Code 4 (SR Upper-layer Header Error)
         and Pointer set to the offset of the Upper-Layer header,
         interrupt packet processing, and discard the packet.
S.16  }



4.2.1.  End with REPLACE-C-SID

When processing an IPv6 packet that matches a FIB entry locally
instantiated as an End SID with the REPLACE-C-SID flavor, the SRH
processing described in Section 4.1 of [RFC8986] is replaced as
follows.

S.01 When an SRH is processed {
S.02  If (IPv6.DA.Argument == 0 and SRH.SegmentsLeft == 0) {
S.03    Stop processing the SRH, and proceed to process the next
        header in the packet, whose type is identified by
        the Next Header field in the routing header.
S.04  }

S.05  If (IPv6.HopLimit <= 1) {
S.06    Send an ICMP Time Exceeded message to the Source Address
        with Code 0 (Hop limit exceeded in transit),
        interrupt packet processing, and discard the packet.
S.07  }

S.08  # Determine the maximum SRH Last Entry
S.09  Set maxLE to ((SRH.HdrExtLen / 2) - 1)

S.10  Initialize 128-bit buffer memory S to 0.
S.11  Initialize local parameter Argument to the value of IPv6.DA.Argument
S.12  Initialize local parameter ActiveSegment to SRH.SegmentList[SRH.SegmentsLeft]

S.13  If (Argument == 0) {
S.14    If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)) {
S.15      Send an ICMP Parameter Problem to the Source Address
          with Code 0 (Erroneous header field encountered)
          and Pointer set to the Segments Left field,
          interrupt packet processing, and discard the packet.
S.16    }

S.17    Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common locator block)

S.18    Decrement SRH.SegmentsLeft by 1

S.19    Set Argument to (128 / NF - 1)
S.20  }
S.21  Else {
S.22    If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry)) {
S.23      Send an ICMP Parameter Problem to the Source Address
          with Code 0 (Erroneous header field encountered)
          and Pointer set to the Segments Left field,
          interrupt packet processing, and discard the packet.
S.24    }

S.25    Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common locator block)

S.26    Decrement Argument by 1
S.27  }

S.28  Initialize local parameter BitLength to the value of NF
S.29  Initialize local parameter BitIndex to (Argument * NF)

S.30  Set S[B..B+BitLength-1] to the value of
       ActiveSegment[BitIndex..(BitIndex+BitLength-1)]
S.32  Set S[B+BitLength..B+BitLength+A-1] to the value of Argument

S.33  Set IPv6.DA to the value of S

S.34  Decrement IPv6.HopLimit by 1

S.35  Submit the packet to the egress IPv6 FIB lookup for transmission
S.36   to the new destination.
S.37 }

4.2.1.1<http://4.2.1.1>.  Upper layer header processing

The upper-layer header processing described in Section 4.1.1 of [RFC8986] is unchanged and reproduced below.

S.01  If (Upper-Layer header type is allowed by local configuration) {
S.02    Proceed to process the Upper-Layer header
S.03  } Else {
S.04    Send an ICMP Parameter Problem to the Source Address
        with Code 4 (SR Upper-layer Header Error)
        and Pointer set to the offset of the Upper-Layer header,
        interrupt packet processing, and discard the packet.
S.05  }