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
