Hi Ole, > If I own and manage three routers, R1 -- R2 -- R3. > 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.
This bit I don't mind that much, but what about: R1 -- R2 -- [open internet] -- R3 or R1 -- [open internet] -- R2 -- R3 or even R1 -- [open internet] -- R2 -- [open internet] -- R3 And what if you're an ISP and R1 is your customer's device? It is in your routing domain but not in your administrative domain. What 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. This has never been clear to me. Quite the opposite actually… There was a reason the text discussing this was tightened while RFC8200 was still a draft. > Conflating the two use cases and claiming that the arguments for why it's a > bad idea on the open Internet also applies to a limited domain, only serves > to polarise the debate. The problem is in the definition (and viability) of a domain. > My suspicion is that the header insertion argument is a straw-man. Not to me. I care about my packets not being mangled by a third party (my ISP). If there is a way that they can mangle the packet and restore it to its original 100% of the time before a box outside the ISP network is able to see it (for debugging or whatever) then I don't mind. I care about observable behaviour, and whether my ISP uses MPLS, SR or something else isn't my problem. But the moment the packet leaves their network it'd better be exactly as I sent it. And the way the domain is defined, as well as the operator experience with limited domains, points to potential leaks. Cheers, Sander
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
