Re: [spring] 64-bit locators

Robert Raszuk <robert@raszuk.net> Thu, 19 December 2019 23:07 UTC

Return-Path: <robert@raszuk.net>
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 CA193120125 for <spring@ietfa.amsl.com>; Thu, 19 Dec 2019 15:07:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 woN7qPaUMYrt for <spring@ietfa.amsl.com>; Thu, 19 Dec 2019 15:07:17 -0800 (PST)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 882C812001A for <spring@ietf.org>; Thu, 19 Dec 2019 15:07:17 -0800 (PST)
Received: by mail-qk1-x734.google.com with SMTP id c17so6091863qkg.7 for <spring@ietf.org>; Thu, 19 Dec 2019 15:07:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SwP1XBXlOVY6VH0I2KjKEaLke8jo6KIfEjCuoq39qs0=; b=CfZ75jNZLJNv96q5cF3VzSNaakE1bVimnfsbF7kUdErMiaYdUIpvmOHINms8TeFYPq VzHg1XS2Pfh0TuVizm2irmyIEMUw4ja/dpmv46KfoTZLVQlDcnSJpb4M7gxmu83/Iutj V4UynzweHyankO3Fl3AC6+RAUz6e6sYTZLG87nM9cEi8qXFpYpjOHNdzWlbVVvzNol// kAIO4DecarfseMp+Nspj1EyZ+PQnpPde1tNXBf4MRlVvwWZHRwcWahCaTX1428PMkjbg Vp5G8IzWByA9gYIiug+TP6DdjGM1woIo/bPAdL0ZxLMOKWVTmN9DEjDzvIzr9zOkZqCu UR9g==
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; bh=SwP1XBXlOVY6VH0I2KjKEaLke8jo6KIfEjCuoq39qs0=; b=nb1cGEzPIBxWMPone0cw13uqbwSxZJe780An+eQmSDIKu5uXalZyRBdTuR7RT/QNeY tjj5r5ubWxKHP6WhPfrYIZdPoM4DCPCd17oZcrcLaoWtLcPUg9Qy/0yrdokBAuISGLvG qa3JYdNUVjclYRlTJnzGjYzPSAJVrUUUt2SHzlWwemCfaWmH8+1bT+41uGMKfz3RMMtc 4mWyQKjqFQOZ0Rm53YZt7D1kk2y2c7rs58xYbWVhBYyChzff1TgNv3gWoygCOjNNsvdq uP4Z2cJUwm5cl6cufx7reErwAq6ti2pYeYbrMpRIum901y/eH93kuwwUqS3OeEJw2nGv 810A==
X-Gm-Message-State: APjAAAWIpY2Iwt9s2nsjpbf7b3cE1Vso3U6xpFmYcxNfG7TAsxNvu243 5b+GWMlSWlZvYsGmkJj4/KM6zYCQ6D8yvfXo8BE6Dw==
X-Google-Smtp-Source: APXvYqzJco62CCmHNv0hErkPfHDPf4U7silKTDCVo9cHRQaKkHpJ/DQ75iP2xazjTyB2JkkfivuDIO+w3ygPcXJR7a4=
X-Received: by 2002:a37:274a:: with SMTP id n71mr10216093qkn.302.1576796836376; Thu, 19 Dec 2019 15:07:16 -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>
In-Reply-To: <CABNhwV1xZEx6_eZpdgvWAmiopXT-SACR1DM_KSeF_JSDvgSSOQ@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 20 Dec 2019 00:07:08 +0100
Message-ID: <CAOj+MMGSbdL2ZP-_uX_464Tov7MV0vu=cmoKpw71-vL8R4HpRw@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: Mark Smith <markzzzsmith@gmail.com>, Alexandre Petrescu <alexandre.petrescu@gmail.com>, SPRING WG <spring@ietf.org>, "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
Content-Type: multipart/alternative; boundary="00000000000050c4a4059a169fb4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/cdz_c1-4QlLXDeRQR--sLRTvHsI>
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: Thu, 19 Dec 2019 23:07:20 -0000

Fixed length of any field LOC:FUNC:ARGs makes no sense to me. What is
optimal for Ron or Mark may not be optimal for me.

While we are at that fixed size of 128 bits of IPv6 also makes no sense -
but that vessel left the harbour a while ago.

Cheers,
R.




On Thu, Dec 19, 2019 at 10:57 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
>
> On Thu, Dec 19, 2019 at 4:17 PM Mark Smith <markzzzsmith@gmail.com> wrote:
>
>>
>>
>> On Thu, 19 Dec 2019, 22:48 Pablo Camarillo (pcamaril), <
>> pcamaril@cisco.com> wrote:
>>
>>> Hi,
>>>
>>> As mentioned in the draft, the choice of the locator length is
>>> deployment specific.
>>> LINE has deployed SRv6 using a locator different than a /64.
>>>
>>
>> This is effectively an appeal to authority.
>>
>> What makes what LINE has done the best and right thing to do?
>>
>> I can already see they're using the IPv4 link-local 169.254/16 prefix in
>> a manner that wildly violates how it is specified to be used in RFC3927.
>> See Slides 9, 12, 24.
>>
>> Tying your IPv6 addressing plan to IPv4 addressing could end up imposing
>> IPv4's addressing limitations on IPv6 - defeating the primary purpose of
>> IPv6 - providing many more addresses than IPv4.
>>
>> Slide 32 shows they're violating RFC 4193 (IPv6 ULAs), because they're
>> using ULA-Cs ('fc') rather than ULA-Ls ('fd'), despite there being no
>> central registry.  Their 40 bit Global ID of "17" could be random, although
>> I'm guessing not, as random numbers would usually have far less zeros in
>> them. These sorts of ULA errors are why I presented "Getting IPv6
>> Addressing Right" at AusNOG this year -
>> https://www.slideshare.net/markzzzsmith/ausnog-2019-getting-ipv6-private-addressing-right
>>  .
>>
>>
>> This is an Internet Draft, so this is the best time to make these sorts
>> of changes, as it is much easier now. When things become RFCs it becomes
>> much harder (and much, much harder when they become Internet Standards).
>>
>> If somebody has deployed Internet Draft level technology, they have to
>> accept the risk that what they've deployed might not comply with the
>> eventual RFC.
>>
>> Regards,
>> Mark.
>>
>
>
>  [Gyan] For IPv6 addressing you can have any length prefix up to /128.  i
> am all for flexibility with vlsm even though may not be widely used.
>
> SRv6 SID encoding differs in that we had 3 fields
> {locator;function;arguments} that I think it makes sense to be fixed in the
> specification as Ron has brought up.
>
> From an operator perspective for programmability as SRv6 deployments with
> or without centralized controller, fixed length of the 3 fields makes sense
> so operators can easily craft ACLs for deployments.
>
> I think we could go crazy with the sizing but I think since 64 bit
> boundary exists today for slaac we could make the locator /64 as well is
> fine.  We could split the other 2 fields evenly 32 bits each or make the
> function longer.  I think we’ll defined sizing is important so SID
> addressing plan is not chaotic.
>
>>
>>
>>
>>> Cheers,
>>> Pablo.
>>>
>>> [1]
>>> https://speakerdeck.com/line_developers/line-data-center-networking-with-srv6
>>>
>>> -----Original Message-----
>>> From: spring <spring-bounces@ietf.org> on behalf of Alexandre Petrescu <
>>> alexandre.petrescu@gmail.com>
>>> Date: Thursday, 19 December 2019 at 09:44
>>> To: "spring@ietf.org" <spring@ietf.org>
>>> Subject: Re: [spring] 64-bit locators
>>>
>>>
>>>
>>>     Le 19/12/2019 à 00:13, Mark Smith a écrit :
>>>     [...]
>>>
>>>     > VLSM [variable length subnet mask] is fundamentally hard,
>>>
>>>     We need VLSM in other places too, such as in ULA prefixes fd and fc.
>>>
>>>     I think it is indeed a difficult to grasp concept, but it is there
>>> for
>>>     growth.
>>>
>>>     Alex
>>>
>>>     >
>>>     > Regards,
>>>     > Mark.
>>>     >
>>>     >     __
>>>     >
>>>     >     In this case, we should probably change the document to reflect
>>>     >     implemented behavior.____
>>>     >
>>>     >     __ __
>>>     >
>>>     >
>>>     >
>>>       Ron____
>>>     >
>>>     >     __ __
>>>     >
>>>     >
>>>     >     Juniper Business Use Only
>>>     >
>>>     >     _______________________________________________
>>>     >     spring mailing list
>>>     >     spring@ietf.org <mailto:spring@ietf.org>
>>>     >     https://www.ietf.org/mailman/listinfo/spring
>>>     >
>>>     >
>>>     > _______________________________________________
>>>     > spring mailing list
>>>     > spring@ietf.org
>>>     > https://www.ietf.org/mailman/listinfo/spring
>>>     >
>>>
>>>     _______________________________________________
>>>     spring mailing list
>>>     spring@ietf.org
>>>     https://www.ietf.org/mailman/listinfo/spring
>>>
>>>
>>> _______________________________________________
>>> spring mailing list
>>> spring@ietf.org
>>> https://www.ietf.org/mailman/listinfo/spring
>>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
> --
>
> Gyan S. Mishra
>
> IT Network Engineering & Technology
>
> Verizon Communications Inc. (VZ)
>
> 13101 Columbia Pike FDC1 3rd Floor
>
> Silver Spring, MD 20904
>
> United States
>
> Phone: 301 502-1347
>
> Email: gyan.s.mishra@verizon.com
>
> www.linkedin.com/in/networking-technologies-consultant
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>