Ole,
Let me highlight a few things before getting into specific comments.
1) The IETF has no consensus about the concept of "limited domains" that
you are referring to. That means that there are no nuances in this
respect: a document that violates RFC8200, violates RFC8200. And if
there is no consensus to formally update RFC8200, then it should not be
violating it.
2) No document has been adopted in that line. Not wg call for adoption
was even done in that line. Hence, the status of an individual proposal
in that respects bears no change when it comes to #1 above.
3) As a wg participant, of course you are entitled to have any view
whatsoever on the topic. But as a wg chair, I would expect you to
respect and pursue the above, which are our existing processes,
practices, and ruls. Otherwise that would seem like an indication of
conflict of interests to me.
Do you want to change that? -- Fine. Write a draft, and get consensus to
push it forward. That's what mere mortals like myself that do not work
for a big powetful vendor are normally required to do.
More in-line....
On 6/12/19 05:34, otr...@employees.org wrote:
>
>>>> comply with it. The onus is on them, not on us asking folks to comply
>>>> with existing standards.
>>>
>>> Yes, we have heard your position on this now.
>>> There is of course a lot more nuance to this argument.
>>
>> could you please explain said 'nuance' in more detail?
>
> I could try, although I fear it will be a rehash of what has already been
> said many times already in this debate.
>
> The IETF and the Internet architecture has a pugnacious relationship with
> packet mangling in the network.
> Steve embodied the Internet architeure principles in the IPv6 protocol suite.
> The IPv6 architecture consists only of routers and hosts (no middleboxes).
> Ensuring that routers would not need to process further into the packet than
> the IPv6 header, and ensure that extension header chains were expensive to
> parse in hardware. As well as requiring all implementations to support IPsec.
Some folks have provided anecdotal evidence that rather than the goal
being "make them hard to process in hardware", the thing is that
software processing was common at the time. (i.e., change in paradigm,
if you want)
[...]
> Now, contrast that with the "real world", I challenge you to find a service
> on the Internet where the packet isn't mangled in some way between the two
> end-points. Be that IPv4 or IPv6.
All these documents are about mangling, as opposed to processing. e.g. a
firewall does process packets, but does not heavy surgery as in SRv6.
> The problems with header insertion on the open Internet are well understood.
Unless you are doing SRv6 in an isolated network (some community
network?)m then you are doing EH insertion in the open Internet.
The argument behind folks pushing EH-insertion is "I have my network
(part of the Internet) and can do SR in a way that I can clean up before
the packets leave the network". But that's still the Internet. And the
issues in draft-smith-6man-in-flight-eh-insertion-harmful still apply.
> That's not what is being discussed here though.
> What is discussed here is what is acceptable to do within a limited domain.
> To packets that _you_ own, i.e. originate and terminate within a domain where
> you control all devices.
>
> If I own and manage three routers, R1 -- R2 -- R3.
IPv{4,6} as internet protocols. We don't have variants of them.
Besides,
H1 --- R1 ---R2 --- R2 ----- Other networks --- H2
is still the internet. The fact that you operate part of it means just that.
> You are saying that if R1 sends a packet to R3, it is not allowed to off-load
> some functions to R2?
> Going to be difficult to do stuff like service chaining then.
>
> When putting in the restrictions in RFC8200, which makes a lot of sense on
> the open Internet, it was always clear that there could and would be
> exceptions to this. Those are the ones we are discussing now.
That is obviously not true.
Even when RFC8200 does not have RFC2119, it does have wording that uses
"must" in the area of not mangling with EHs. In fact, I should remind
you that rfc2460bis wouldn't go past its first IETF LC without making
this change and making the topic crystal clear.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
