Nope. I have no opinion on SRH. If it solves some networks problem or improves functionality then it should proceed through standards to production.
My issue will always be that causing control plane punts and possible exceptions in old code in other peoples networks because you want to violate RFC8200, want to save the overhead of encapsulation and haven’t specified a workable mechanism to insure no leakage of your malformed packets out of your administrative domain is selfish at best. Anyone can do whatever they like on their network but it used to be that it was beholden on us to be good neighbours. We should stop creating tools that contain “spew ‘bogus’ packets onwards” settings. > On 4 Oct 2021, at 05:22, Eliot Lear <l...@lear.ch> wrote: > > As Robert wrote, I think your issue is not with this draft, but with SRH. > >> On 04.10.21 02:26, Michael Simpson wrote: >> Generally it's any proposition that violates RFCs that are in place in long >> deployed hardware but where there is no sufficient mechanism to not leak the >> packets onto other peoples networks >> >> In this instance its a knee jerk response to "what’s the worst that could >> happen" after 40 years experience on connected networks, not that prestel >> was that connected. >> >>>> On 3 Oct 2021, at 15:22, Eliot Lear <l...@lear.ch> wrote: >>> >>> I'm struggling to understand whether your issue is with this draft or with >>> any extension header. >>> >>> Eliot >>> >>> On 03.10.21 15:17, Mike Simpson wrote: >>>> Given that every time a vendor suggests altering the fundamentals of the >>>> ipv6 header the reason given for not just using encapsulation and >>>> therefore avoiding upsetting the 2 decades worth of running kit is to save >>>> the few bytes of overhead it would produce. >>>> >>>> 1) Do we not have enough bogus packets on the internets. >>>> And >>>> 2) just because you can’t define the “harm it will cause” doesn’t mean >>>> that it’s not going to cause harm. >>>> >>>> Man generally seems quite fallible imho. >>>> >>>> >>>>> On 3 Oct 2021, at 05:13, Brian E Carpenter <brian.e.carpen...@gmail.com> >>>>> wrote: >>>>> >>>>> Ron, >>>>> >>>>> The first sentence cites RFC8402 which unambiguously describes SR as a >>>>> limited domain protcol (limited to an "SR domain", that is.) >>>>> >>>>> So within such a domain, this describes using 128 bit quantities called >>>>> Segment Identifiers that in some cases, but apparently not in the formats >>>>> defined here, has the same structure as an IP address. >>>>> >>>>> Does that harm the Internet, even if it leaks? It might disappoint the >>>>> sender, as any sender of a bogus packet is disappointed, but apart from >>>>> that, >>>>> who is damaged? >>>>> >>>>> Regards >>>>> Brian Carpenter >>>>> >>>>> >>>>>> On 02-Oct-21 09:34, Ron Bonica wrote: >>>>>> Folks, >>>>>> >>>>>> >>>>>> Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new >>>>>> >>>>> SID types that can occupy the Destination Address field of an IPv6 >>>>> header. See Sections 4.1, 4.2, and 4.3 of the draft for details. >>>>> >>>>>> >>>>>> The SPRING WG has issued a call for adoption for this draft. >>>>>> >>>>>> >>>>>> It is not clear that these SID types can be harmonized with the IPv6 >>>>>> addressing architecture. >>>>>> >>>>>> >>>>>> Does anyone have an opinion? >>>>>> >>>>>> >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> >>>>>> Juniper Business Use Only >>>>>> >>>>>> >>>>>> -------------------------------------------------------------------- >>>>>> 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 >>>>> >>>>> -------------------------------------------------------------------- >>>>> >>>> -------------------------------------------------------------------- >>>> 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
