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

[Brian E Carpenter <[e-mail]>]

On 03-Aug-23 07:51, Toerless Eckert wrote:
> On Wed, Aug 02, 2023 at 10:52:44AM -0700, Tom Herbert wrote:
>> RFC8799 is good to define limited domains but is not normative. I
>> think that's appropriate.
> 
> Agreed.

+1. And the reason we used the new phrase "limited domain" was
exactly because it was new. All the older terms like "controlled
environment" seemed to carry baggage and preconceptions.

> 
>> If there were a normative definition of
>> limited domains then we risk bifurcating Internet protocols.

That issue is of course discussed in RFC 8799. I've got nothing
to add, except that it isn't a risk; it's already happened (and
HbH is a good and messy example).

There is a technical debt in the RFC, a list of functional
requirements:
https://www.rfc-editor.org/rfc/rfc8799.html#section-6-5

That, it seems to me, is where there is real work to do (but not
in 6man). Of course, a domain policy could include rules like
"Allow any HbH" or "Allow only the following HbH options".

Note for Toerless: the obvious example of a well-defined limited
domain is of course RFC 8994.

    Brian

> 
> I think this depends on how we define it. If we effectively want to define
> paths which are not "Internet paths", i think we are effectively doing this
> implicitly in a lot of drafts, for example outlining the requirements
> you need to match so you can forego congestion control on such paths
> (aka: need to use circuit breakers instead). And i think "non Internet"
> == "controlled environemnts" works well, because "non Internet" AND "not controlled"
> typically just means "broken home networks that cause SP insolvency" ;-))
> 
>> 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.
> 
> Did you comment on Andrew's draft, would love to read it, haven't tried to
> catch up.
> 
> I think different ethertype can be a an interesting way to profile different
> uses of IPv6, but i don't think it religiously implies creation of a new
> protocol.
> 
>> IMO,
>> bifurcating core protocols for limited domains would have  adverse
>> effects on implementation and protocol interoperability.
> 
> We alreasdy have so many features that are getting or not getting enabled
> on different network paths. I really don't sdee ethertype or HbH header as
> something different. I am more concerned of figuring out how we use
> the tools we have for security, safety and simplicity. Doing name-calling
> "this is or is not IPv6" is i think not very helpfull.
> 
>> With regards to HBH processing, the reference to limited domains is
>> not for defining the protocol, or about processing, but for basic
>> deployability.
> 
> Sure. But intent for traffic to be for a controlled network (ne limited domain)
> by mean of ethertype could be one help with deployability. I have really not
> decided what i think overall pro/con, but i am surely not interested in the
> argument "if it's not IPv6 ethertype, it's not IPv6".
> 
>> The baseline support needed for HBH options to be
>> usable to anyone is that they are not arbitrarily dropped in the
>> network.
> 
> Please define arbitrarily.
> 
>>   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.
> 
> I think i kinda agree, but somehow we need to be more explanatory/descriptive
> about this.
> 
> Cheers
>      Toerless
> 
>> 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
>>> --------------------------------------------------------------------
>