On Sun, 29 Dec 2019, 16:10 Miya Kohno, <miya.ko...@gmail.com> wrote: > I agree with Robert. > Modern language is generous about type ([*] as an example). C also has a > concept of "union", though. . >
We are talking about network protocols, not programming languages. A union is an internal data representation function to save memory. The access type to that memory is encoded in the source code implicitly. In networking protocols that type information is encoded explicitly in type fields or field definitions themselves. > The stubborn discussion of IPv6 address will hinder creativity and > innovation for the future. > When you have a 24 year old protocol (RFC1883) that is still interoperable with the newest implementations, that has literally been implemented in billions of devices, and where continued interoperability is critical, because it's expected to be the most deployed and used protocol of all in the future, creativity and innovation are naturally hindered. That's the price you have to be willing to pay if you want to use and benefit from a commodity and therefore cheap to use protocol. This is why the SPRING approach in a number of cases doesn't make sense. Use IPv6 because it is commodity; then propose quite radical and non-compliant changes that customise the protocol for SPRING's special cases. Customising a commodity protocol defeats the purpose of using it in the first place - because your customisations decommodify it. You lose the scales of economy, the interoperability with existing implementations and the existing knowledge, history and experience with the commodity protocol. There is room for change in IPv6, but only in certain places, and they have to be compatible with existing implementations. RFC7217 is a recent example of that, as is RFC6437. IPv6 is like at 24 year old house for lease. When you rent it, some rooms can be used for different purposes without too many issues e.g. a lounge as a bedroom, or a bedroom as a study. There's enough flexibility in those rooms that they can be multipurpose (although in some cases a lounge room would not be private enough to be a satisfactory bedroom, and perhaps too central to the house). However you can't make the bathroom a lounge, or the kitchen into a toilet. Those rooms have fixed and strictly defined purposes and infrastructure, making them unsuitable for any other purpose. If you owned the house you could make those changes - at great expense. SPRING is renting IPv6. SPRING doesn't own IPv6. Look for lounge rooms you can make bedrooms, or bedrooms you can make studies. Don't try to covert a bathroom into a lounge or a kitchen into a toilet (EH insertion, PSP, uSID, NH=59 implicit payload ...). > [*] https://www.python.org/dev/peps/pep-0484/#union-types > > Miya > > On Sun, Dec 29, 2019 at 1:19 AM Robert Raszuk <rob...@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 >> >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
