Re: [spring] 64-bit locators

I agree with Robert.
Modern language is generous about type ([*] as an example). C also has a
concept of "union", though.

The stubborn discussion of IPv6 address will hinder creativity and
innovation for the future.

[*] https://www.python.org/dev/peps/pep-0484/#union-types

Miya

On Sun, Dec 29, 2019 at 1:19 AM Robert Raszuk <robert@raszuk.net> wrote:

>
> > 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:
>>
>
> All correct.
>
> And that means that if you consider FUNC:ARGs bits as IIDs there is no
> conflict at all and current SRv6 SIDs are compliant verbatim with section
> 2.5.4 of RFC4291. Maybe SRv6 drafts should all make it clear.
>
> And yes they are only significant to the destination of the packet too.
> Just keep in mind that destination is an encapsulation destination == each
> segment end.
>
> Best,
> R.
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>