Yes, Mark, we are talking about network protocols. And what's remarkable is that the "declarative" nature of network protocol can ensure backward compatibility and co-existing possibility between the commodity and the new innovation.
Miya On Sun, Dec 29, 2019 at 3:13 PM Mark Smith <markzzzsm...@gmail.com> wrote: > > > 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
