Actually, upon reviewing this one, I'm leaning back toward simply rejecting
both this erratum and erratum 7644. As we discussed earlier in the thread on
this one, the best fix (assuming the working group agrees is a fix is merited,
of course) is a draft to update or replace the base spec.
—John
> On Sep 21, 2023, at 13:06, Alexander Okonnikov
> wrote:
>
> Hi Owen,
>
> RFC 2328 doesn't require MTUs to be matched. It unambiguously says that
> "Interface MTU ... is larger than the router can accept on the receiving
> interface ...". RFC 2328 even doesn't say something about MTU of re
Hi Owen,
RFC 2328 doesn't require MTUs to be matched. It unambiguously says that
"Interface MTU ... is larger than the router can accept on the receiving
interface ...". RFC 2328 even doesn't say something about MTU of receiving
interface. So, if implementation on router A performs check for MT
> On Sep 21, 2023, at 10:50, Alexander Okonnikov
> wrote:
>
> Hi WG,
>
> Regarding the errata - the errata claims that cause of it is the bug in an
> implementation, sending DBD with Interface MTU = 0. Maybe it is so, but it
> seems that real bug is in implementation(s), receiving and dropp
Hi WG,
Regarding the errata - the errata claims that cause of it is the bug in an
implementation, sending DBD with Interface MTU = 0. Maybe it is so, but it
seems that real bug is in implementation(s), receiving and dropping such DPD.
Both RFCs - 5838 and 5340 - inherit rules for receiving DBD
> On Sep 20, 2023, at 7:02 PM, Owen DeLong wrote:
>
> Given what I have seen, I would argue for semantics of 0=valid only on
> virtual link. On others, must not be 0 and must reflect actual interface MTU.
If you feel further specification is necessary, it should be done in a draft
rather tha
Given what I have seen, I would argue for semantics of 0=valid only on virtual
link. On others, must not be 0 and must reflect actual interface MTU.
Owen
> On Sep 20, 2023, at 12:34, Tony Przygienda wrote:
>
> errata is _not_ precise enough and the errata as proposed will cause more
> proble
Indeed ... a tunnel (GRE, IPSec, etc...) is an interface. How is this
different from any other interface from an OSPF point of view If mtu is
configured on such interface (and in most cases it should be) that value
should be used in OSPF not 0.
Either way it has zero reassemblage to the "OSPF vir
I agree - though I don’t think this is a case of underspecification. OSPF
virtual links should not be confused with OSPF adjacencies over tunnels and
there shouldn’t be any need for the added text.
Thanks,
Acee
> On Sep 20, 2023, at 3:42 PM, John Scudder wrote:
>
> Without commenting on the
Without commenting on the other aspects,
> On Sep 20, 2023, at 3:34 PM, Tony Przygienda wrote:
>
> 3. the MTU "largest datagram" needs to be errate'd to something more precise
> on top.
Generally, errata are not the right way to fix “this is underspecified” kinds
of problems. The right way is
errata is _not_ precise enough and the errata as proposed will cause more
problems than it solves from my experience
1. what is the semantics of 0 here? Don't care? Then 0 can be sent on
tunnel MTU and tunnel must stay up if one side sends "don't care"? If
semantics of 0 is "no value" then same c
I’m beginning to get a feeling of Deja MTU…
Acee
> On Sep 19, 2023, at 19:15, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC5340,
> "OSPF for IPv6".
>
> --
> You may review the report below and at:
> https://www.rfc-e
The following errata report has been submitted for RFC5340,
"OSPF for IPv6".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7649
--
Type: Technical
Reported by: Owen DeLong
Section: A.3.3 (i
13 matches
Mail list logo
