As an operator I have to admit – I always have slight concerns when people start referring to these limited domain applications – and here is why.
Many networks – including the one I run at the moment – are segregated for a host of reasons. Separate IGP levels – a few ASN’s – BGP labeled unicast stitching etc etc. All of these networks however are under central control – and where necessary we stitch across the boundaries (bgp labeled unicast, binding SID’s etc). This network splitting and segregation is necessary – but the question then becomes – how do we define the domain. Yes – technically we could say within a single autonomous system. We could say within a single IGP area – many different ways to define this – but in reality – each time we have to cross such a boundary – we have to find a way to stitch – to inter-operate – and to make both sides of the network talk to each other. Each time we introduce methods that are incompatible with each other – the complexity grows – and the more possibility of leakage between those domains of things that may do harm grows – because unlike a truly external boundary, the controls between “internal” boundaries are often more loosely defined for a host of reasons. For this reason I really prefer to avoid these “limited” domain scenarios that outright violate other standards – because it can – and does – create complexity in large networks that by necessity, but it technical, geo-political, organizational or other reason, have had to “split” the domain – but still want the end to end functionality. Thanks Andrew From: spring <spring-boun...@ietf.org> on behalf of Ron Bonica <rbonica=40juniper....@dmarc.ietf.org> Date: Tuesday, 5 October 2021 at 00:00 To: Brian E Carpenter <brian.e.carpen...@gmail.com>, Tony Przygienda <tonysi...@gmail.com> Cc: SPRING WG <spring@ietf.org>, "6...@ietf.org" <6...@ietf.org> Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 Brian, Is there any limit to the degree that one Internet Standard can violate another, so long as that violation is constrained to a limited domain? For example, if I wanted to reduce the size of IPv6 header by shrinking the source and destination addresses to 64 bits each, would that be OK? Ron Juniper Business Use Only -----Original Message----- From: Brian E Carpenter <brian.e.carpen...@gmail.com> Sent: Monday, October 4, 2021 4:05 PM To: Tony Przygienda <tonysi...@gmail.com> Cc: Ron Bonica <rbon...@juniper.net>; 6...@ietf.org; SPRING WG <spring@ietf.org> Subject: Re: draft-filsfilscheng-spring-srv6-srh-compression-02 [External Email. Be cautious of content] Tony, On 05-Oct-21 02:32, Tony Przygienda wrote: > Taking this new "philosophy of limited domain" to its bitter > conclusion > > A is Internet Standard > B is also Internet Standard for "Limited Domain" that violates A C is > also Internet Standard for "Limited Domain" that violates A D is also > Internet Standard for "Limited Domain" that violetes C > > so by transitive chain D violates C and hence A but not B. Hence D and B can > be deployed together (maybe) but not any other combination. > > So what purposes will IETF serve. To define 4 different "standards" that have > "limited domain violation dependencies" amongst each other but based on > algebra closure can sometimes be deployed together. And we will track this > and call that "standards" ? Really ? There's an attempted analysis of this issue at https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8799.html*name-the-scope-of-protocols-in-l__;Iw!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3faGG7y06gGZe$<https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8799.html*name-the-scope-of-protocols-in-l__;Iw!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3faGG7y06gGZe$> (which is not, of course, an IETF document). Brian > > --- tony > > > > > > On Sun, Oct 3, 2021 at 6:13 AM Brian E Carpenter <brian.e.carpen...@gmail.com > <mailto: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 <mailto:i...@ietf.org> > > Administrative Requests: > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3faGG74XUosUG$<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3faGG74XUosUG$> > > > > <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3faGG74XUosUG$<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3faGG74XUosUG$> > > > > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org <mailto:i...@ietf.org> > Administrative Requests: > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6> > __;!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3f > aGG74XUosUG$ <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3faGG74XUosUG$<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3faGG74XUosUG$> > > > -------------------------------------------------------------------- > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
