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

[Tom Herbert <[e-mail]>]

On Wed, Aug 2, 2023 at 10:11 AM Toerless Eckert <[e-mail]> wrote:
>
> Agreed.
>
> IntArea would certainly be good for an IETF track version of something like 8799
> However, i think we can already well brainstorm here, what degree of coordination
> (intradomain, intraprovider interdomain, federation, Internet) would relate to
> what processing of HbH header. Maybe really have the process the other way around,
> where e.g.: in SRv6 work started in SPRING, and the header was outsourced to 6MAN
> and now maybe with HbH where we work out what can work how and get architecture
> review or addtl broader documentation from INTAREA...

Toerless,

RFC8799 is good to define limited domains but is not normative. I
think that's appropriate. If there were a normative definition of
limited domains then we risk bifurcating Internet protocols. For
instance, there could be one version of IPv6 for limited domains, and
one version of IPv6 for everyone else. In fact, this is pretty much
what the proposal to give SRv6 its own EtherType endeavours do. IMO,
bifurcating core protocols for limited domains would have  adverse
effects on implementation and protocol interoperability.

With regards to HBH processing, the reference to limited domains is
not for defining the protocol, or about processing, but for basic
deployability. The baseline support needed for HBH options to be
usable to anyone is that they are not arbitrarily dropped in the
network. Saying that HBH Options is usable in limited domains roughly
defines a deployment where we believe they are usable. The fuzziness
about what exactly a limited domain is actually beneficial in this
case as we're not restricted to some rigid architectural definition or
requirements.

Tom

>
> Cheers
>     Toerless
>
> On Wed, Aug 02, 2023 at 04:02:57PM +0000, Ron Bonica wrote:
> > Toerless,
> >
> > Many things developed in the IETF (e.g., MPLS, DiffServ, IPv6 Extension Headers) rely on a common understanding of "limited domains". However, if there is any such common understanding, I can't find it in an IETF consensus document.
> >
> > Because this issue has greater scope than IPv6, it probably doesn't belong in the 6man WG. Maybe INTAREA?
> >
> > Maybe the AD's can give us some direction. Or at very least, recommend a higher dose of medication 😉
> >
> >                                                                  Ron
> >
> >
> >
> >
> > Juniper Business Use Only
> > -----Original Message-----
> > From: Toerless Eckert <[e-mail]>
> > Sent: Wednesday, August 2, 2023 11:28 AM
> > To: Ron Bonica <[e-mail]>
> > Cc: Michael Richardson <[e-mail]>; [e-mail]
> > Subject: why ? off topic and Beyond Charter (was: draft-ietf-6man-hbh-processing)
> >
> > [External Email. Be cautious of content]
> >
> >
> > 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> > > __;!!NEt6yMaO-gk!AaQzVNEurQaf1v0d6kAUb9Z8fWDkMvEBhrpvS-ubJFFstcfYh0Chl
> > > T1eW7JtPUL26ow7olXkVbPG$
> > > --------------------------------------------------------------------
> >
> > --
> > ---
> > [e-mail]
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --
> ---
> [e-mail]
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------