Hey Mark, Thank you for presenting your house architectural perspective.
Mine is much simpler ... I compare IPv6 128 bits of address to a train. First 64 bits is a locomotive and undercarriage which we better leave alone. However what goes into the remaining 64 bits are passengers travelling along. As such some may be just tourists, some may be monks having completely different missions in life. Yet another set may be gold miners etc ... I really do not see a need to redo the train in general just to accommodate different types of passengers to travel along. IMHO there is a room there for all of the above. Sure changing ethertype and designing new tracks is a very attractive option. So is shortening the train engine to reduce the overhead - and I do like those (in fact proposed some of this already both publicly and privately), but Ron's mail is a bit shooting in between. Anyhow I will leave it at that here, Best, R. On Mon, Jun 15, 2020 at 11:52 PM Mark Smith <markzzzsm...@gmail.com> wrote: > On Tue, 16 Jun 2020 at 07:31, Robert Raszuk <rob...@raszuk.net> wrote: > > > > Hi Ron, > > > > True ! > > > > But pls do not take my response as an attempt to derail your shot. It > was rather a delicate attempt to put it on the right tracks towards the > truth target. > > > > The IPv6 addressing model is 25 years old, going by the publication > date of RFC 1881 (1995). > > IPv6 is like a 25 year old house. The purpose of some rooms is > flexible or somewhat flexible - a bedroom can be turned into a study, > or, depending on where it is located, a lounge room can be used as a > bedroom. > > Other rooms in the house are fixed purpose and either are impossible > to change, or cannot be changed without a massive expense. It is > almost impossible to effectively change a kitchen into a bedroom, or a > bathroom into a kitchen. > > At some point the house can't effectively be changed, and it is better > to design a new house. IPv6 isn't a house that is on the drawing board > any more, or is a house that is early in its construction such that > rooms' functions can be easily changed with minimal consequences. > > If SPRING want a new forwarding architecture and a new addressing > architecture, then a new house needs to be designed. > > Regards, > Mark. > > > Best, > > Robert. > > > > On Mon, Jun 15, 2020 at 11:26 PM Ron Bonica <rbon...@juniper.net> wrote: > >> > >> Robert, > >> > >> > >> > >> While this is an interesting question, it is orthogonal to the question > that I posed to Darren. > >> > >> > >> > >> Ron > >> > >> > >> > >> > >> > >> > >> > >> Juniper Business Use Only > >> > >> From: Robert Raszuk <rob...@raszuk.net> > >> Sent: Monday, June 15, 2020 3:33 PM > >> To: Ron Bonica <rbon...@juniper.net> > >> Cc: Darren Dukes (ddukes) <ddu...@cisco.com>; Aijun Wang < > wang...@chinatelecom.cn>; i...@ietf.org; spring@ietf.org > >> Subject: Re: About the upper layer header processing in RFC8754(SRH) > >> > >> > >> > >> [External Email. Be cautious of content] > >> > >> > >> > >> Hi Ron, > >> > >> > >> > >> I think this is not the question of RFC 8754. > >> > >> > >> > >> To me (and trust me I am not alone) this is much more of the question > what IPv6 address means. How flexible we can use all bits regardless if we > are talking SRv6 or not. > >> > >> > >> > >> Do we think that https://tools.ietf.org/html/rfc4291 section 2.5 still > holds ? Do we need to keep stretching notion of interface to logical > interfaces mapped to functions ? > >> > >> > >> > >> Then take projects completely unrelated to segment routing ... don't we > see evident that we can encode a lot of useful information in the lowest > significant bits of the IPv6 address without each time proposing new RH ? > >> > >> > >> > >> Best, > >> > >> R. > >> > >> > >> > >> > >> > >> > >> > >> On Mon, Jun 15, 2020 at 9:08 PM Ron Bonica <rbonica= > 40juniper....@dmarc.ietf.org> wrote: > >> > >> Darren, > >> > >> > >> > >> Does the SID described in RFC 8754 represent any of the SIDs in the > Network Programming Draft? In any other document? > >> > >> > >> > >> > Ron > >> > >> > >> > >> > >> > >> Juniper Business Use Only > >> > >> From: ipv6 <ipv6-boun...@ietf.org> On Behalf Of Darren Dukes (ddukes) > >> Sent: Monday, June 15, 2020 12:21 PM > >> To: Aijun Wang <wang...@chinatelecom.cn>; i...@ietf.org; > spring@ietf.org > >> Subject: Re: About the upper layer header processing in RFC8754(SRH) > >> > >> > >> > >> [External Email. Be cautious of content] > >> > >> > >> > >> Hello Aijun. > >> > >> > >> > >> No update to rfc8754 is necessary. Rfc8754 was written so new sids can > be defined in other documents independently. > >> > >> > >> > >> section 4.3.1 says: > >> > >> This document and section define a single SRv6 SID. Future documents > >> > >> may define additional SRv6 SIDs. In such a case, the entire content > >> > >> of this section will be defined in that document. > >> > >> > >> > >> > >> > >> Thanks > >> > >> Darren > >> > >> (Written on mobile) > >> > >> > >> > >> ________________________________ > >> > >> From: ipv6 <ipv6-boun...@ietf.org> on behalf of Aijun Wang < > wang...@chinatelecom.cn> > >> Sent: Sunday, June 14, 2020 10:15 PM > >> To: i...@ietf.org; spring@ietf.org > >> Subject: About the upper layer header processing in RFC8754(SRH) > >> > >> > >> > >> Hi, Folks: > >> > >> RFC8754(SRH) section 4.3.1.2(https://tools.. > ietf.org/html/rfc8754#section-4.3.1.2) describes the process of upper > layer header as the followings: > >> > >> IF (Upper-layer Header is IPv4 or IPv6) and > >> > >> local configuration permits { > >> > >> Perform IPv6 decapsulation > >> > >> Resubmit the decapsulated packet to the IPv4 or IPv6 module > >> > >> } > >> > >> ELSE { > >> > >> …… > >> > >> } > >> > >> And in network programming draft section 9.1( > https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15#section-9.1), > one new Ethernet Next Header Type(143) is proposed. > >> > >> > >> > >> Although the detail process of this new next header are described in > the network program draft, does it need to update the section 4.3.1.2 of > RFC8754 to reflect the process of new header type(143)? > >> > >> > >> > >> Best Regards > >> > >> > >> > >> Aijun Wang > >> > >> China Telecom > >> > >> > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> i...@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > i...@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
