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