Re: [spring] Beyond SRv6.

[Mark Smith <[e-mail]>]

On Mon., 2 Sep. 2019, 21:09 Robert Raszuk, <[e-mail]> wrote:

>
> > Are uSID values going to be entirely pseudo-random?
>
> I see no reason why not ...
>
> Networks are managed by some form of NMS. NMS can generate such values and
> abstract it with a "node_name_usid" string for any additional processing
> and human abstraction.
>
> If that is the only concern I think we are done then.
>

No. You haven't dealt with the other issues I've highlighted in the email
link I provided earlier. As I pointed out there, I think the only place you
can put uSIDs is in the IID field, and I went to the effort of providing
RFC references.

I'm getting off this merry go round. When SPRING comes up with an out of
the ordinary idea, the first thing to do is check the IPv6 RFCs to see if
they will accommodate the idea.

This draft and the EH insertion draft show that this isn't and hasn't
happened.



The only issue is that if you happen to have hierarchical IGP you will not
> be able to summarize them - but I don't think that this would be a
> showstopper to any deployment.
>
> Best,
> R.
>
>
>
>
>
> On Mon, Sep 2, 2019 at 12:24 PM Mark Smith <[e-mail]> wrote:
>
>>
>>
>> On Mon., 2 Sep. 2019, 17:58 Robert Raszuk, <[e-mail]> wrote:
>>
>>> Hi Mark,
>>>
>>>
>>>> The uSID proposal is taking the position that all the bits after the
>>>> high order prefix are available for any purpose. This is not correct, and
>>>> would violate a number of standards track RFCs, including the IPv6
>>>> Addressing Architecture RFC (RFC 4291) and the ULA RFC (RFC 4193).
>>>>
>>>> In particular, 40 bits of a ULA prefix, between /8 and /48, the Gobal
>>>> ID, must be pseudo random. This is the most critical property of ULA
>>>> addresses and prefixes, as it is the solution to the problem ULAs are
>>>> designed to solve.
>>>>
>>>
>>> RFC 4193 says about Global_ID allocation:
>>>
>>>    The local assignments are self-generated and do not need any central
>>>    coordination or assignment, but have an extremely high probability of
>>>    being unique.
>>>
>>>
>> Are uSID values going to be entirely pseudo-random?
>>
>> "
>>
>> 3.2.1 <https://tools.ietf.org/html/rfc4193#section-3.2.1>.  Locally Assigned Global IDs
>>
>>    Locally assigned Global IDs MUST be generated with a pseudo-random
>>    algorithm consistent with [RANDOM <https://tools.ietf.org/html/rfc4193#ref-RANDOM>]."
>>
>>
>>
>>> So in some the case operator may choose to make such "local assignment"
>>> of Global ID to be per router not per network. And that is all what is
>>> needed for uSID. uSID address blocks does not need to be continues.
>>>
>>> It also does not contradict with any RFC does it ? What breaks if I use
>>> more then one self generated Global ID in my network ?
>>>
>>> Note that the above question goes way beyond any SR related discussion
>>> so perhaps deserves a separate 6man thread.
>>>
>>> Best,
>>> R.
>>>
>>>