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
