[IPv6] why ? off topic and Beyond Charter (was: draft-ietf-6man-hbh-processing)

[Toerless Eckert <[e-mail]>]

Thanks, Ron

a) rfc8799

My main issue with rfc8799 is the introdcution of the term "limited domain" instead of
staying with "controlled environments", which i remember having been the the main term before
(or controlled networks). For example, i worked with global enterprise networks with 100,000
IP routers in the 200x, and calling that a "limited domain" is irritating. Likewise
NASA deep space mission networks. 

Do you have any specific technical functions in mind when you say "finish work on rfc8799" ?

b) Why do you call this beyond charter ? Do you mean 6man charter ?

If work for controlled environments is supposedly off-charter, why then did we do e.g. rfc8754 ?

The mayority of use of IPv6 i would argue is not across the Internet. MPLS or SRv6 packets are
not Internet packets. They may just carry Internet packets as payload. The Internet is 
a service. In many cases also just as an overlay. If the 6MAN charter is not inclusive to the mayority
use of IPv6, then it needs to change.

For example, we are now working in DetNet on several options per-hop latency control of packet
forwarding, and that ultimately would lead IMHO best to a HbH header (and/or routing header given how
we also need path steering, but obviously, we'd like to keep one of the two steering headers we already
defined - rfc6554/8754). But DetNet wisely is not claiming to want to make this work "for the Internet", but
for controlled environments (single domain actually i think, but i think there is no reason why
it wouldn't work already for federated controlled environments).

Cheers
    Toerless

On Wed, Aug 02, 2023 at 02:01:21PM +0000, Ron Bonica wrote:
> Hi Michael,
> 
> This posting may be off topic and beyond the 6man charter, but I can't resist responding. Apologies in advance to the chairs.
> 
> Years ago, networks were limited by there lack of interoperability. A frame relay network couldn't communicate with an ATM network and neither could communicate with an ethernet. So, the Fathers of the Internet superimposed an internetworking layer. IP, ICMP, TCP and UPD instantiated this layer.
> 
> Then, at least for a while, there was a single monolithic Internet. Because most participants were funded by a small handful of governments, their goals, acceptable use policies, forwarding policies, routing policies and security policies were all very similar to one another.
> 
> While this model was easy to comprehend, it was not sustainable. Routing protocols could not scale to infinity. So, the Internet was broken into domains, with Intradomain Gateway Protocols supporting intradomain routing and an Interdomain Routing Protocol (aka, BGP) supporting interdomain routing. BGP introduced the concept of an Autonomous System (AS). An AS is a special case of a limited domain that is applicable to Interdomain Routing.
> 
> According to RFC 4271, an AS appears to other ASs to have a single coherent interior routing plan and presents a consistent picture of what destinations are reachable through it. While AS's can propose reachability through one another, the cannot change one another's interior routing plane. Moreover, reachability proposals can be accepted or rejected by BGP policy. Exterior BGP (eBGP) gateways enforce BGP policy.
> 
> Another special case of limited domains is applicable to forwarding behavior. An ISP might enforce an Expedited Forwarding policy for packets with one DHCP marking and a Best Effort policy for packets with another DHCP marking. In this case, the ISP might remark (or even drop) EF packet received from other domains, because it has no way to be compensated for the expedited service.
> 
> Another special case of limited domains is applicable to security. One ISP may accept one class of packets from a neighboring ISP, while another ISP may not. Many IETF RFCs refer to this kind of limited domain in their Security Considerations sections. Sadly, the IETF does not have a consensus document that defines a limited domain. RFC 8799 is a good start, but it was published on the Independent Stream and, therefore, does not represent IETF consensus.
> 
> Maybe we should complete work on RFC 8799?
> 
>                                                                                    Ron
> 
> 
> 
> 
> 
> 
> Juniper Business Use Only
> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: Saturday, July 29, 2023 1:42 PM
> To: Ron Bonica <[e-mail]>; [e-mail]
> Subject: Re: [IPv6] draft-ietf-6man-hbh-processing
> 
> 
> Ron Bonica <rbonica=[e-mail]> wrote:
>     > The Internet is a loosely confederated group of "limited domains". Each
>     > limited domain maintains its own forwarding and routing policy. HBH
>     > processing, as it is defined in RFC 8200, is OK within a limited
>     > domain. It provides yet another tool for deployment of that limited
>     > domain's forwarding and policies.
> 
> It's an interesting view.
> 
> So, the "unlimited Internet" is just a path across a bunch of limited domains, where the sender does not know which limited domains will be used.
> I think that is a useful change from how we used to think about the Internet, because it might be that we know something about the nearby limited domain,
> and something else about the receivers limited domain.   It's the unknown
> part in the middle that gets in our way.
> 
> An interesting thing about Ben Schwartz and Co's RISAV proposal is that it gives a way for those two limited domains to communicate directly.
> 
>     > Deployment of the HBH across limited domains may not be a very good
>     > idea, because it provides a tool for one limited domain to influence
>     > the forwarding and routing polices of another. Can you think of a
>     > single HBH option for which the above statement is not true? (The
>     > question is not rhetorical.)
> 
> If the HBH didn't influence things, then we wouldn't bother!
> So by definition, it's true.
> But, you are missing a key phrase in this:
> 
>      it provides a tool for one limited domain to influence
>      the forwarding and routing polices of another IN AN UNAUTHORIZED WAY
> 
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
---
[e-mail]