> that domains using SRH filter it at ingress and egress edges. *it* is a key here.
If document says (as I presume Suresh explained) that such ingress filtering will be based on destination address of the packets being the new SRv6 prefix or any other infra address of the AS - all is legal and great. But you keep stating that filtering can also happen based on presence of SRH alone - irrespective of the destination address of the packet. That is something I have hard time to agree with. Best, R. On Mon, Oct 10, 2022 at 5:35 PM Joel Halpern <j...@joelhalpern.com> wrote: > There appear to be two separate issues, only one of which affects this > document. > > The issue that affects this document is that the SRH document explicitly > requires that domains using SRH filter it at ingress and egress edges. > That is what is relevant for the document at hand. And while some folks > have envisioned use cases that violate that, the RFC is clear that it is > prohibited. (My reading is that this also applies to SRv6 in general, > even when compressed SIDs with no SRH are used.) > > The question of whether, in doing enforcing that requirement a domain > may filter more packets that should not be received is about how the > operator chooses to enforce the requirement. We are not specifying how > the operator does the enforcement. > > The question of what transit domains are permitted to do is one that > reasonable people appear to be able to differ on. But it is not a > relevant question for this draft. > > Yours, > > Joel > > On 10/10/2022 10:31 AM, Ole Troan wrote: > > Joel, > > > >> On 10 Oct 2022, at 15:36, Joel Halpern <j...@joelhalpern.com> wrote: > >> > >> Eric, you seem to be objecting to something I did not say. I have not > asked, and do not expect, for the document to mandate or even suggest that > arbitrary domains should drop packets with SRH. I will note that given > that SRH is explicitly for limited domains, an operator who chooses to drop > such packets is well within his rights. And I am told there are such > operators. But that is not what I asked for this document. > > No, that would violate rfc8200. > > > > O. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
