Re: [spring] Managing "global" SIDs

Kireeti Kompella <kireeti.kompella@gmail.com> Wed, 24 July 2019 19:34 UTC

Return-Path: <kireeti.kompella@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 228DD120688 for <spring@ietfa.amsl.com>; Wed, 24 Jul 2019 12:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=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 Rsg6OSCJMh0H for <spring@ietfa.amsl.com>; Wed, 24 Jul 2019 12:33:59 -0700 (PDT)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 D1E6712067C for <spring@ietf.org>; Wed, 24 Jul 2019 12:33:58 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id w17so2358888qto.10 for <spring@ietf.org>; Wed, 24 Jul 2019 12:33:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DK3nP6M5vyGTu1kMcnEiev+3vDLoQyGi2XMUbWUgznk=; b=NmwcL/9My54GhV5OF+Iy748wsrxkfaxQrHOiJ+82FzCOgpnpIadYy4aznfDTElQ/xK icqs6ZugSu2IHzmOACl8IThKWgYSA20z/dqZE4ZqzFLWGIlOPxSYuZwww+ofakb68MBh 5GyqC6T9x0KEeEZhwBmQwnwtJZABr1nEOpN9vzDsmamjkIG0CyV8iN3QmvJvwLM7xYZu CpzRBgslGWwxt6XWyArA1/JEg1d3mTD0RR215X9547gzj9VT4tOtvlaKIXnmGtXbAk+Z JZbHIDFg9Jj54XFXXwfZM8s6fhgH6qx2LLfS+06FM3c9wXXj1Ncnro5tlZ6JylTLZsba ZJFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DK3nP6M5vyGTu1kMcnEiev+3vDLoQyGi2XMUbWUgznk=; b=TBgQ4yy9JR72lLKQik85pDyrxx0l27jvXv8jccb0btdKA29mUP+q9HbKiQoe58yaFl oiXCwiruhWjDNw44k1mUOgywgsJXYEEu02DelDMi2NOqaHc7R+IjkN3K/aUeR2gSFOxF BNwqsAHY5X8tcDuKLMFU8W79gej6P8fKSl2rAeVdk+ibS3KKHrb5RMPP7HDyCKIO1e/h vyEmwSqSrTawYiN7wUBty9oCCHe1naZS8r8nidS3H+1iXPc6/qB/AjhZ/DFzxAcX543A TwsR0GGVYBBJA5AwC4nD/kaTqYbKj1UP4gDlNNMkSfNVUJkwxxKJz4u58CkiX79/LnfG mkkQ==
X-Gm-Message-State: APjAAAXn7h7lU/jtvC9ANa5F2o0CjNtQVFIOUpZCcijLGI76o+6rSxJU O5IgWgZyfulsMvGNYZhSuco=
X-Google-Smtp-Source: APXvYqwqe5LCg2wNV+F5m4Q8xd6PNe4fDsxAQfkk1Bk9XspOrjxJaRcASjVP/afmEYpu+JNsmQ7dIQ==
X-Received: by 2002:aed:3325:: with SMTP id u34mr57882714qtd.324.1563996837904; Wed, 24 Jul 2019 12:33:57 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:21c4:4962:8228:ea20? ([2001:67c:1232:144:21c4:4962:8228:ea20]) by smtp.gmail.com with ESMTPSA id l19sm27652350qtb.6.2019.07.24.12.33.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jul 2019 12:33:57 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-C9A24CF5-6F97-4BBF-AD62-D59119F382F0"
Mime-Version: 1.0 (1.0)
From: Kireeti Kompella <kireeti.kompella@gmail.com>
X-Mailer: iPhone Mail (16F203)
In-Reply-To: <CAA=duU1YJDPFKtpXF+i3_YsqoOaN_n-P5dvVkTn3OY6nJ1=P2w@mail.gmail.com>
Date: Wed, 24 Jul 2019 15:33:55 -0400
Cc: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, Robert Raszuk <rraszuk@gmail.com>, SPRING WG List <spring@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <B0C452DC-F77A-47FF-B920-3BD24204D764@gmail.com>
References: <CABRz93VUjBJhCB8aq7goV6_ws=0jJb5UeOPSeapP4c3+WUbH8w@mail.gmail.com> <CA+b+ER=pKm=KrQP3BO+=Vz6ByLzvZvmeTFeqJr9ntiUg_L5UBA@mail.gmail.com> <CABRz93W=S2P9AoMmwhUxMtjXvE6K6q1TB3ax5kMwBO=qhptcQw@mail.gmail.com> <AM0PR03MB382888B3783231FA5A629D2C9DC60@AM0PR03MB3828.eurprd03.prod.outlook.com> <CAA=duU1YJDPFKtpXF+i3_YsqoOaN_n-P5dvVkTn3OY6nJ1=P2w@mail.gmail.com>
To: "Andrew G. Malis" <agmalis@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/W1yFCDpB607c4fpbMWvt9rBssq0>
Subject: Re: [spring] Managing "global" SIDs
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: Wed, 24 Jul 2019 19:34:06 -0000

Sasha,

Yes, this helps, but let’s separate persistent and deterministic.  (The latter is probably better terminology than “static” and “dynamic”.)  Deterministic means the operator knows a priori what SID stouter will get.  

DHCP servers support persistence (my phone gets the same IP, even after being away for several hours).  This doesn’t require configuration.

DHCP also allows for determinism, to Andy’s point.  That requires lots of configuration.

A simple reply to the list on whether or not you believe that global SIDs need to be persistent and/or deterministic would be helpful to hone in on the best protocol for allocation.

So far, the count is, 1 for persistent but not necessarily deterministic (me), 1 for persistent and deterministic (Robert).

Kireeti

> On Jul 24, 2019, at 12:38, Andrew G. Malis <agmalis@gmail.com> wrote:
> 
> Sasha,
> 
> Most "normal" DHCP servers require manual configuration of some sort if you want to guarantee persistence of the assigned IP address (i.e. "static" DHCP). So we're back to "manual" management, even if the results of the manual management are conveyed by a dynamic protocol.
> 
> Cheers,
> Andy
> 
> 
>> On Wed, Jul 24, 2019 at 11:53 AM Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:
>> Robert, Kireeti and all,
>> 
>> I think that both loopbacks and their association with SIDs should be kept persistent.
>> 
>>  
>> 
>> Whether such persistency is provided by the means of static configuration, or by the means that are external to some dynamic protocol is a different question.
>> 
>> E.g., a “normal” DHCP client (like my office computer) may think that it obtains a dynamic IP address in the company network from the DHCP server every time I turn it on, but the DHCP server actually takes care to assign to it the same IP address every time.
>> 
>>  
>> 
>> Does this help in any way?
>> 
>>  
>> 
>> Regards,
>> 
>> Sasha
>> 
>>  
>> 
>> Office: +972-39266302
>> 
>> Cell:      +972-549266302
>> 
>> Email:   Alexander.Vainshtein@ecitele.com
>> 
>>  
>> 
>> From: spring <spring-bounces@ietf.org> On Behalf Of Kireeti Kompella
>> Sent: Wednesday, July 24, 2019 6:36 PM
>> To: Robert Raszuk <rraszuk@gmail.com>
>> Cc: SPRING WG List <spring@ietf.org>
>> Subject: Re: [spring] Managing "global" SIDs
>> 
>>  
>> 
>> Hi Robert,
>> 
>>  
>> 
>> On Wed, Jul 24, 2019 at 11:09 AM Robert Raszuk <rraszuk@gmail.com> wrote:
>> 
>> Hi Kireeti,
>> 
>>  
>> 
>> I would like to challenge a bit your fundamental assumption which is to state that while loopbacks are very important and locally significant and warrant manual/nms provisioning SIDs are not. 
>> 
>>  
>> 
>> Actually, what I said at the mike is that I believe that both loopbacks and global SIDs should be managed by DHCP.  But that's a distraction; the point at hand is whether global SIDs should be managed "manually" (or by NMS or equivalent) (i.e., static), or by a protocol (say DHCP) (i.e., dynamic).  You say the former ... thanks for the feedback.
>> 
>>  
>> 
>>  -- 
>> 
>> Kireeti
>> 
>> 
>> ___________________________________________________________________________
>> 
>> This e-mail message is intended for the recipient only and contains information which is 
>> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
>> transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
>> and all copies thereof.
>> ___________________________________________________________________________
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring