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 protected]>
Sent: Monday, October 4, 2021 4:05 PM
To: Tony Przygienda <[email protected]>
Cc: Ron Bonica <[email protected]>; [email protected]; SPRING WG <[email protected]>
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$
(which is not, of course, an IETF document).
Brian
>
> --- tony
>
>
>
>
>
> On Sun, Oct 3, 2021 at 6:13 AM Brian E Carpenter <[email protected]
> <mailto:[email protected]>> 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 protected] <mailto:[email protected]>
> > 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$
> >
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected] <mailto:[email protected]>
> Administrative Requests:
> 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$
>
>
> --------------------------------------------------------------------
>
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
