Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

From: Andrew Alston <[email-masked]>
Date: Mon, 4 Oct 2021 21:17:53 +0000

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 <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Date: Tuesday, 5 October 2021 at 00:00
To: Brian E Carpenter <[email-masked]>, Tony Przygienda <[email-masked]>
Cc: SPRING WG <[email-masked]>, "[email-masked]" <[email-masked]>
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 <[email-masked]>
Sent: Monday, October 4, 2021 4:05 PM
To: Tony Przygienda <[email-masked]>
Cc: Ron Bonica <[email-masked]>; [email-masked]; SPRING WG <[email-masked]>
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 <[email-masked] <mailto:[email-masked]>> 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
> > [email-masked] <mailto:[email-masked]>
> > 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
> [email-masked] <mailto:[email-masked]>
> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>