Hi Joel, Great so this closes this little exchange.
And just to clarify my comments were triggered by your statements not the actual text in the subject draft. The text in the draft as it is now looks fine to me. Best, R. On Mon, Oct 10, 2022 at 6:17 PM Joel Halpern <j...@joelhalpern.com> wrote: > What I asked for, and I believe Suresh plans for, is to note that not > using the reserved block complicates the filtering for ingress and > egress. I do not expect this document to discuss what other methods of > filtering could be applied. > > Yours, > > Joel > On 10/10/2022 11:40 AM, Robert Raszuk wrote: > > > 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
