Re: [spring] Managing "global" SIDs

Hey Kireeti,

Just one observation on your informal pool :)

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

As deterministic really requires persistence, a better pool would be to
just see who thinks SIDs need to be deterministic or not.

And with that if you are doing such pool it may make sense to ask for this
separately for node SIDs vs adj SIDs vs other locally significant SIDs.

Putting all such SID types into one basket may not result in meaningful
survey :)

To restate my opinion was that node SIDs should be deterministic and
provisioned by given network's NMS system of the local choice. In the case
of SRv6 node SID maybe it's loopback's address.

Adj. SIDs IMHO could be algorithmically derived.

Special app/use SIDs - hard to tell as it really depands on the use case.

Cheers,
R.

On Wed, Jul 24, 2019 at 9:34 PM Kireeti Kompella <kireeti.kompella@gmail.com>
wrote:

> 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
>> <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
>>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>