Re: [spring] 64-bit locators

Mark Smith <markzzzsmith@gmail.com> Sat, 28 December 2019 00:56 UTC

Return-Path: <markzzzsmith@gmail.com>
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 BFAD7120137 for <spring@ietfa.amsl.com>; Fri, 27 Dec 2019 16:56:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Level:
X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 7Z5Kxc6qvYIv for <spring@ietfa.amsl.com>; Fri, 27 Dec 2019 16:56:49 -0800 (PST)
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D611200E5 for <spring@ietf.org>; Fri, 27 Dec 2019 16:56:46 -0800 (PST)
Received: by mail-ot1-x32e.google.com with SMTP id k16so33712013otb.2 for <spring@ietf.org>; Fri, 27 Dec 2019 16:56:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UUVBiB10scmjCbJp4mvA70FTBbwTJehBN0Fyb05FXeM=; b=LJCrGWiyWUfU6EiKFSK42X6FcWlM4qj3FioQGn59Ro1q2mOzX3NE+VWUC4udtgC2xv 6pLqUoQtlxtrXbsuTm3dPeQuGm2XU5z+T65TJVkIS85w6pyLQL8DNbWDLGS+A5+9XBh1 GCJw9iv9S6sm/PqE/jGk5iyVlZwWOj8PhNhVlbjmIOlbCkqzpKVIEHhPedhviufduWCN yfePRhLACCzNpuHtbVsKeex73P9tF3+VdPaihy+hcrYk9SoexJRueVgDsngH9cXSV3XX sE4Z0cST5q8eQT6VyetWTQpuq4ybZviCAXcao7tTLM7PGTa0DqBHoXK+sCjogZXwA8WS p2NQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UUVBiB10scmjCbJp4mvA70FTBbwTJehBN0Fyb05FXeM=; b=gjcUdlqNLmZWPxLKxScd94Pxi/RlPFYeIqZfezmJK3pM2DrJUznRWVMT4d6l6YIpic 9UL8/pNRiG3HO6uZ9J7A1PIMDIS1frc1i9TB53cKw8DHg25Y1j5dkfLH7o+e1485YkA3 CbcTNoEy3OLuWqL4gEPnFF2aWdnAabT05Ue2x3i4Z4Ofe6I4U4F+5C9URJ+mQnW1n8ED Ja3dS+oLGVTYks61XAt1n9OE52kJfnewY9UxijhrHK5WA5wAFMnlPeTi27WQiYFBsKgp fclyIejck5cwXyARj2R0v788jSssVS/meOGvJsgfq7gaNiWaczexYRBndMEYXyFdvT2x bveA==
X-Gm-Message-State: APjAAAXLdYidjFLOYZ1Es57dRFDgsQBCTV3pNoNUPWgWQd97ad0K4t93 PQRdt7szLnmUPT0A8ZUrYouJBltig5z4D36EXa8=
X-Google-Smtp-Source: APXvYqxb1/3eFrx+Qam8ey4Sz2/xEe53TiYAJGi/omjN4KYEaGHzCB+j83Vm04f1Yr2hU8P8U2ymeZw7shW17f/Dpxk=
X-Received: by 2002:a05:6830:151a:: with SMTP id k26mr41850577otp.74.1577494606044; Fri, 27 Dec 2019 16:56:46 -0800 (PST)
MIME-Version: 1.0
References: <BN7PR05MB5699D85CC99CB23B1B573901AE530@BN7PR05MB5699.namprd05.prod.outlook.com> <CAO42Z2yAH4ECeB+PGRS98HgZHXtTq3iX1x6aMSPjKgS6O1GDAQ@mail.gmail.com> <8f5607c9-645a-ea88-e2a7-a4bed8206fc8@gmail.com> <63F5AA66-AEF8-4278-B98C-D3C53AC5A60A@cisco.com> <CAO42Z2x-5NUYHAzjBAR3je7EoPde=-autOXyta5EvqDydbVMWA@mail.gmail.com> <CABNhwV1xZEx6_eZpdgvWAmiopXT-SACR1DM_KSeF_JSDvgSSOQ@mail.gmail.com> <CAOj+MMGSbdL2ZP-_uX_464Tov7MV0vu=cmoKpw71-vL8R4HpRw@mail.gmail.com> <069e6021-537c-422a-37da-f090a6ac334b@gmail.com> <DBBPR03MB5415CDB6870E8E6B69522E40EE2D0@DBBPR03MB5415.eurprd03.prod.outlook.com> <CAOj+MMHOqJWo+ofewx5LF81zA7sGNGwdBgh3X1CSujZbTw9TCw@mail.gmail.com> <BN7PR05MB56995F5D8A02A63E0317A3D9AE2C0@BN7PR05MB5699.namprd05.prod.outlook.com> <CAOj+MMFwK2S0NDVeF-AeTEuLgHJGt6mmVZki6sobuf2EGpQmpw@mail.gmail.com> <BN7PR05MB56993D9F5BEEDABC5A40AB79AE2A0@BN7PR05MB5699.namprd05.prod.outlook.com> <CAOj+MMELEvcnimBBppqMHhuJtgvPFJjDQn1-J06Ro9Dx8=YQKA@mail.gmail.com> <CAO42Z2yrdgWwNTz_a7fHEC+G+WERv789YLtoAjH90BZH-rDW7Q@mail.gmail.com> <CAOj+MMFsz3OX4+6gjEU_J6-Q7ra251j2YFVYjQO1yA6dOr3t2Q@mail.gmail.com>
In-Reply-To: <CAOj+MMFsz3OX4+6gjEU_J6-Q7ra251j2YFVYjQO1yA6dOr3t2Q@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sat, 28 Dec 2019 11:56:19 +1100
Message-ID: <CAO42Z2xDiRXzyDzwmdAzYwk1qB9gUp5QLpMLhZfiqEg5C0Lajw@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: Ron Bonica <rbonica@juniper.net>, SPRING WG <spring@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/SD-YxuBEdj1t9gKD6St5-u2Rp5g>
Subject: Re: [spring] 64-bit locators
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: Sat, 28 Dec 2019 00:56:51 -0000

On Sat, 28 Dec 2019 at 09:45, Robert Raszuk <robert@raszuk.net> wrote:
>
> Hi Mark,
>
> Happy New Year !
>
>>
>> The key point is that RIDs look like IPv4 addresses, but are not. They only have adopted the formatting convention of IPv4 addresses. They're 32 bit quantities. They could have just as easily been formatted as 0x hex strings e.g. 0xffffffff for my example. Their continued use as 32 bit quantities and identifiers in IPv6 supporting OSPFv3 shows how decoupled from both IPv4 and IPv6 they are.
>
>
> We are again in 100% agreement here. That was exactly my analogy to RID made to Ron. But on the other hand let's also recognize that this is pretty common to assign router_id to be yr loopback address in number of protocols.
>


Right. I've done that. However, it is a convention, nothing more. In
OSPF and BGP the RID is not an IPv4 address even if it looks like one,
and is never used as an IPv4 address.

SIDs are used as IPv6 addresses. When SIDs are used as IPv6 addresses,
they must be compliant with the IPv6 specifications.


>>
>> SIDs on the other hand are at some point in time used as IPv6 destination addresses.
>
>
> Well SID locators (of variable length) need to assure packet delivery to a segment end points. That is a subtle but very important difference.
>
>>
>> That means they have to either always comply with IPv6 address requirements - RFC4291 - or be converted to meet IPv6 address requirements when they're used as IPv6 addresses (e.g. they're 64 bit quantities that are then used as an IPv6 Interface Identifier by prepending an IPv6 addressing compliant /64 prefix)
>
>
> IPv6 address fields are 128 bits (for good or for bad of it).
>And there are no :: or : there to the point Alex made earlier. What matters is to make sure that routing prefixes deliver packets to correct destinations.
>
> I am very puzzled reading those messages what is the point regarding all remaining bits outside of locator ? If this is to say RFC4291 did not defined a SID - sure you won - game over. But at the same time I do not see anything in RFC4291 which would prohibit me to put any bit sequence I like in the remaining (least significant) bits of the address.

If you limit yourself to the Interface Identifier portion of the IPv6
address, you can encode other semantics in that portion that are
significant to the end points. That is permitted by RFC 7136,
"Significance of IPv6 Interface Identifiers:"

"In all cases, the bits in an IID have no generic semantics; in other
   words, they have opaque values.  In fact, the whole IID value MUST be
   viewed as an opaque bit string by third parties, except possibly in
   the local context."

While the packet is being forwarded towards an end point, those
end-point semantics are to be ignored, because IPv6 forwarding is
longest match across all 128 bits:

BCP 198/RFC 7608, "IPv6 Prefix Length Recommendation for Forwarding"


Regards,
Mark.


>And I think this is the crux of the little discussion here.
>





> Cheers,
> R.
>
>
>
>