Re: [spring] 64-bit locators

[Robert Raszuk <[e-mail]>]

> > 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.