Re: [Lsr] [Technical Errata Reported] RFC5340 (7649)

[John Scudder]

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 20, 2023, at 2:05 PM, Acee Lindem  wrote:
> 
> 
> 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://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7649__;!!NEt6yMaO-gk!BYmUJjHFQ4KMZJsCjZgl_d0_PYcaJK_iJ6PuAAKdEtrss5IOJOR_WhubhtnyFvmisUP-WbpxnM0kOok$
>> 
>> --
>> Type: Technical
>> Reported by: Owen DeLong 
>> 
>> Section: A.3.3 (in part)
>> 
>> Original Text
>> -
>> Interface MTU
>> The size in bytes of the largest IPv6 datagram that can be sent
>> out the associated interface without fragmentation.  The MTUs of
>> common Internet link types can be found in Table 7-1 of [MTUDISC].
>> Interface MTU should be set to 0 in Database Description packets
>> sent over virtual links.
>> 
>> 
>> Corrected Text
>> --
>> Interface MTU
>> The size in bytes of the largest IPv6 datagram that can be sent
>> out the associated interface without fragmentation.  The MTUs of
>> common Internet link types can be found in Table 7-1 of [MTUDISC].
>> Interface MTU should be set to 0 in Database Description packets
>> sent over OSPF virtual links. This rule should not be applied to tunnel
>> or other software interfaces.
>> 
>> Notes
>> -
>> OSPF Virtual links carry only OSPF packets so MTU negotiation is not needed 
>> and this provision makes sense. For interfaces that have an actual MTU, even 
>> though they may be "virtual" interfaces, they are not "virtual links" in the 
>> intended meaning of this paragraph. As such, this change will provide 
>> clarification and remove ambiguity from the current standard. At least one 
>> popular router vendor implements this RFC as MTU = 0 sent on all GRE 
>> interfaces which results in incompatibilities with most other router 
>> platforms which expect an actual value. The router vendor points to this 
>> provision in the RFCs as justification for their implementation. It is 
>> (arguably) a legitimate, if nonsensical interpretation of the existing text.
>> 
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>> 
>> --
>> RFC5340 (draft-ietf-ospf-ospfv3-update-23)
>> --
>> Title   : OSPF for IPv6
>> Publication Date: July 2008
>> Author(s)   : R. Coltun, D. Ferguson, J. Moy, A. Lindem
>> Category: PROPOSED STANDARD
>> Source  : Open Shortest Path First IGP
>> Area: Routing
>> Stream  : IETF
>> Verifying Party : IESG
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!BYmUJjHFQ4KMZJsCjZgl_d0_PYcaJK_iJ6PuAAKdEtrss5IOJOR_WhubhtnyFvmisUP-Wbpxjmyny-M$
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Technical Errata Reported] RFC5340 (7649)

[Owen DeLong]

> 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 receiving 
> interface. So, if implementation on router A performs check for MTU mismatch 
> (i.e. from router A point of view they are expected to be equal), it is 
> misinterpretation of RFC 2328.

Perhaps… However, it’s such a widespread misinterpretation that if you do a 
search for “OSPF stuck in EXSTART”, almost every result is a discussion of how 
this happens when the interface MTUs don’t match:

https://www.google.com/search?client=safari=en=ospf+stuck+in+exstart=UTF-8=UTF-8
 ospf stuck in exstart - Google Search
google.com

> 
> Yes, RFC 5838 says something another - it, for unknown reason, says, that RFC 
> 2328 says that DBD to be rejected if Interface MTU value in DBD is greater 
> than the receiving interface's MTU. I don't know why it is needed to compare 
> those two values, but, again, even in this case there is no requirement for 
> MTU matching. There is requirement for to be not larger, and this is 
> different requirement. Please, correct me if I'm wrong.

Well… sort of… If A must not be larger than B and B must not be larger than A, 
then A must equal B.

True, the router with the larger MTU will accept the smaller MTU 
(theoretically, though FRR OSPFD does report the received smaller MTU in the 
DBD as a problem and won’t progress the negotiation and this is also true of 
many other implementations).

Hard to imagine how one could send a package complaint with a 0 MTU, so this 
doesn’t seem all that unreasonable absent special casing for MTU 0 beyond the 
“OSPF virtual-link” scenario intended in RFC5340 and RFC5838.

Owen


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Technical Errata Reported] RFC5340 (7649)

[Alexander Okonnikov]

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 MTU mismatch 
(i.e. from router A point of view they are expected to be equal), it is 
misinterpretation of RFC 2328.

Yes, RFC 5838 says something another - it, for unknown reason, says, that RFC 
2328 says that DBD to be rejected if Interface MTU value in DBD is greater than 
the receiving interface's MTU. I don't know why it is needed to compare those 
two values, but, again, even in this case there is no requirement for MTU 
matching. There is requirement for to be not larger, and this is different 
requirement. Please, correct me if I'm wrong.

On the other hand, while behavior of implementation J on router B is somewhat 
different from RFC 2328/RFC 5838, it is not disruptive, but only in case that 
behavior of router A in part of processing received DBD would be implemented 
correctly.

Thank you.

> 21 сент. 2023 г., в 22:49, Owen DeLong  написал(а):
> 
> 
> 
>> 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 dropping such DPD.
>> 
>> Both RFCs - 5838 and 5340 - inherit rules for receiving DBD from RFC 2328. 
>> RFC 2328 says follow (section 10.6):
>> 
>> "... If the Interface MTU field in the Database Description packet indicates 
>> an IP datagram size that is larger than the router can accept on the 
>> receiving interface without fragmentation, the Database Description packet 
>> is rejected. ..."
>> 
>> Obviously, 0 is not larger than IP datagram size that can be accepted on the 
>> receiving interface. I guess that the size is greater than 0, but, even if 
>> it is equal to 0, then 0 (Interface MTU value in DBD) is not larger than 0 
>> (acceptable size of receiving datagram).
>> 
> 
> The problem isn’t rejection due to MTU too large, but rejection due to MTU 
> mismatch.
> 
> Router A from virtually any other vendor sees MTU on (e.g. GRE) interface as 
> 1476 and sends 1476 in DBD.
> Router B from vendor J has MTU on interface as 1476, but instead sends 0 in 
> DBD.
> Router A detects MTU mismatch and shuts down the session unless configured 
> for ignore-mtu-mismatch.
> 
> So the discussion of what routers should do if the MTU is too large is kind 
> of not relevant to the errata.
> 
>> Now regarding essense of the problem. I don't agree with the errata - it is 
>> clear enough that 'virtual links' are mentioned in context of OSPF, hence, 
>> 'OSPF virtual links' rather than some other 'virtual links' or 'IP virtual 
>> links' are implied there.
> 
>> But, I think that decision taken in the subjected implementation is good 
>> trade-off for tunnel interfaces, which doesn't violate procedure for 
>> receiver side, and, thus, even doesn't require implementation of 
>> 'ignore-mtu' functionality on receiving side. Actually, issues, related to 
>> path MTU discovery nature and applicable to OSPF virtual links, are equally 
>> applicable to OSPF interfaces deployed as tunnels. I don't see how DBD 
>> Interface MTU can help in solving problems with possible fragmentation, PMTU 
>> blackholes on transit and so on. My view is that actual problem, which DBD 
>> Interface MTU is intended to mitigate, is on tunnel egress OSPF router. Due 
>> to nature of tunnels, tunneled IP datagrams can ingress OSPF router via any 
>> of multiple transport interfaces, each of which may have its own MRU. What 
>> will be MRU of tunnel interface in this case? It is OK if all those 
>> transport interfaces have the same MRU value, and tunnel interface MRU will 
>> be stable, but what if it is not the case? We would need to adjust tunnel 
>> MRU every time some transport interface added/removed. It seems that 
>> omitting MRU check via DBD Interface MTU for tunnel interfaces would be more 
>> or less good solution which doesn't require OSPF spec modification (beside 
>> writing '0' into Interface MTU field). Any way, current OSPF (per my 
>> knowledge) doesn't provide mechanism for OSPF DBD receiver to signal actual 
>> MRU to OSPF DBD sender, and thus rejecting DBD on receive doesn't look 
>> better than broken PMTUD (PMTUD blackhole).
> 
> I don’t disagree with your point here, but my point is that the RFC should 
> provide some clear choice of behaviors that doesn’t result in a session being 
> stuck due to a detected, but non-obvious MTU mismatch that requires one to 
> analyze a packet capture to find.
> 
> If router A sends 0 and router B drops the session for MTU mismatch, but 
> “show interface” reports on both A and B show an MTU of 1476, I think we 
> should all be able to 

Re: [Lsr] [Technical Errata Reported] RFC5340 (7649)

[Owen DeLong]

> 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 dropping such DPD.
> 
> Both RFCs - 5838 and 5340 - inherit rules for receiving DBD from RFC 2328. 
> RFC 2328 says follow (section 10.6):
> 
> "... If the Interface MTU field in the Database Description packet indicates 
> an IP datagram size that is larger than the router can accept on the 
> receiving interface without fragmentation, the Database Description packet is 
> rejected. ..."
> 
> Obviously, 0 is not larger than IP datagram size that can be accepted on the 
> receiving interface. I guess that the size is greater than 0, but, even if it 
> is equal to 0, then 0 (Interface MTU value in DBD) is not larger than 0 
> (acceptable size of receiving datagram).
> 

The problem isn’t rejection due to MTU too large, but rejection due to MTU 
mismatch.

Router A from virtually any other vendor sees MTU on (e.g. GRE) interface as 
1476 and sends 1476 in DBD.
Router B from vendor J has MTU on interface as 1476, but instead sends 0 in DBD.
Router A detects MTU mismatch and shuts down the session unless configured for 
ignore-mtu-mismatch.

So the discussion of what routers should do if the MTU is too large is kind of 
not relevant to the errata.

> Now regarding essense of the problem. I don't agree with the errata - it is 
> clear enough that 'virtual links' are mentioned in context of OSPF, hence, 
> 'OSPF virtual links' rather than some other 'virtual links' or 'IP virtual 
> links' are implied there.

> But, I think that decision taken in the subjected implementation is good 
> trade-off for tunnel interfaces, which doesn't violate procedure for receiver 
> side, and, thus, even doesn't require implementation of 'ignore-mtu' 
> functionality on receiving side. Actually, issues, related to path MTU 
> discovery nature and applicable to OSPF virtual links, are equally applicable 
> to OSPF interfaces deployed as tunnels. I don't see how DBD Interface MTU can 
> help in solving problems with possible fragmentation, PMTU blackholes on 
> transit and so on. My view is that actual problem, which DBD Interface MTU is 
> intended to mitigate, is on tunnel egress OSPF router. Due to nature of 
> tunnels, tunneled IP datagrams can ingress OSPF router via any of multiple 
> transport interfaces, each of which may have its own MRU. What will be MRU of 
> tunnel interface in this case? It is OK if all those transport interfaces 
> have the same MRU value, and tunnel interface MRU will be stable, but what if 
> it is not the case? We would need to adjust tunnel MRU every time some 
> transport interface added/removed. It seems that omitting MRU check via DBD 
> Interface MTU for tunnel interfaces would be more or less good solution which 
> doesn't require OSPF spec modification (beside writing '0' into Interface MTU 
> field). Any way, current OSPF (per my knowledge) doesn't provide mechanism 
> for OSPF DBD receiver to signal actual MRU to OSPF DBD sender, and thus 
> rejecting DBD on receive doesn't look better than broken PMTUD (PMTUD 
> blackhole).

I don’t disagree with your point here, but my point is that the RFC should 
provide some clear choice of behaviors that doesn’t result in a session being 
stuck due to a detected, but non-obvious MTU mismatch that requires one to 
analyze a packet capture to find.

If router A sends 0 and router B drops the session for MTU mismatch, but “show 
interface” reports on both A and B show an MTU of 1476, I think we should all 
be able to agree that isn’t a desirable outcome.

> Sorry in advance for long complicated speech.

Nothing wrong with a good detailed analysis. Frankly, I have no problem if we 
want to go the other way and say that all tunnel interfaces should send MTU 0 
in the DBD or find some other way to ensure that implementations are compatible 
without creating unnecessary problems.

Some phrase that notes the inherent fictional nature of tunnel interface MTUs 
and requires routers to use the smaller of the DBD MTUs (sent or received), 
requiring sending the actual interface MTU, or requiring sending 0 MTU would 
all be acceptable outcomes as far as I’m concerned.

The problem here is ambiguity resulting in incompatible implementations. You’ve 
amusingly explained why one vendor’s interpretation is both logical and 
nonsensical presenting a great detailed argument for both sides. From my 
perspective, the key here is to improve the specification such that one cannot 
create an incompatible, yet compliant implementation. I have no dog in the 
fight of which set of choices we use to achieve that.

Owen

> 
> Thanks.
> 
>> 21 сент. 2023 г., в 12:49, Acee Lindem  написал(а):
>> 
>> 
>> 
>>> On Sep 20, 2023, at 7:02 PM, Owen DeLong  wrote:
>>> 
>>> Given what I have seen, I 

Re: [Lsr] [Technical Errata Reported] RFC5340 (7649)

[Alexander Okonnikov]

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 from RFC 2328. RFC 
2328 says follow (section 10.6):

"... If the Interface MTU field in the Database Description packet indicates an 
IP datagram size that is larger than the router can accept on the receiving 
interface without fragmentation, the Database Description packet is rejected. 
..."

Obviously, 0 is not larger than IP datagram size that can be accepted on the 
receiving interface. I guess that the size is greater than 0, but, even if it 
is equal to 0, then 0 (Interface MTU value in DBD) is not larger than 0 
(acceptable size of receiving datagram).

Also, RFC 5838 contains (section 2.7) incorrect rephrasing of RFC 2328:

"... As specified in Section 10.6 of [OSPFV2], the Database Description packet 
will be rejected if the MTU is greater than the receiving interface's MTU for 
the address family corresponding to the instance. ..."

"Is larger than the router can accept on the receiving interface" (RFC 2328) 
and "is greater than the receiving interface's MTU" (RFC 5838) - strictly 
speaking, two ones are not the same. My understanding of goal of the procedure 
in section 10.6 of RFC 2328 is to ensure that lower layer maximum receive unit 
value (Maximum Receive Unit in PPP, Maximum Frame Size in IEEE 802.3, and so 
on) is enough to accept IP datagrams with size, specified in Interface MTU of 
DBD message (of course, with needed math for corresponding lower layer 
encapsulations), such that there would not be blackholing on lower layer on 
receipt. I don't see reason to check Interface MTU from DBD against MTU of 
receiving interface. MTU of receiving interface is not the same as MRU of 
receiving interface, and MTU of the interface is irrelevant to receiving 
datagrams.

RFC 1812 says follow in section 3.3.4:

"... However, a router SHOULD be willing to receive a packet as large as the 
maximum frame size even if that is larger than the MTU. ..."

It is common that for regular interfaces MRU usually eqauls to MTU. But for 
tunnels this equality doesn't hold, due to, e.g. assymetric routing. And even 
for regular interfaces, while MRU=MTU usually, strictly speaking two ones are 
not have to be equal.

By the way, "without fragmentation" in 10.6 of RFC 2328 looks unclear for me. 
I'm not aware about fragmentations performed on receiving, and do you? Either 
this phrase inapplicable for receiving IP datagrams, or, probably, 'without 
reassembly' was assumed there?

Now regarding essense of the problem. I don't agree with the errata - it is 
clear enough that 'virtual links' are mentioned in context of OSPF, hence, 
'OSPF virtual links' rather than some other 'virtual links' or 'IP virtual 
links' are implied there. But, I think that decision taken in the subjected 
implementation is good trade-off for tunnel interfaces, which doesn't violate 
procedure for receiver side, and, thus, even doesn't require implementation of 
'ignore-mtu' functionality on receiving side. Actually, issues, related to path 
MTU discovery nature and applicable to OSPF virtual links, are equally 
applicable to OSPF interfaces deployed as tunnels. I don't see how DBD 
Interface MTU can help in solving problems with possible fragmentation, PMTU 
blackholes on transit and so on. My view is that actual problem, which DBD 
Interface MTU is intended to mitigate, is on tunnel egress OSPF router. Due to 
nature of tunnels, tunneled IP datagrams can ingress OSPF router via any of 
multiple transport interfaces, each of which may have its own MRU. What will be 
MRU of tunnel interface in this case? It is OK if all those transport 
interfaces have the same MRU value, and tunnel interface MRU will be stable, 
but what if it is not the case? We would need to adjust tunnel MRU every time 
some transport interface added/removed. It seems that omitting MRU check via 
DBD Interface MTU for tunnel interfaces would be more or less good solution 
which doesn't require OSPF spec modification (beside writing '0' into Interface 
MTU field). Any way, current OSPF (per my knowledge) doesn't provide mechanism 
for OSPF DBD receiver to signal actual MRU to OSPF DBD sender, and thus 
rejecting DBD on receive doesn't look better than broken PMTUD (PMTUD 
blackhole).

Sorry in advance for long complicated speech.

Thanks.

> 21 сент. 2023 г., в 12:49, Acee Lindem  написал(а):
> 
> 
> 
>> 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 than an Errata (as John already mentioned). However, note that this is 
> a 

Re: [Lsr] [Technical Errata Reported] RFC5340 (7649)

[Acee Lindem]

> 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 than an Errata (as John already mentioned). However, note that this is a 
solved problem as most vendors have implemented the “ip ospf ignore-mtu” 
interface configuration. 

Thanks,
Acee



> 
> Owen
> 
> 
>> On Sep 20, 2023, at 12:34, Tony Przygienda  wrote:
>> 
>> 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 consideration applies AFAIS. So the errata would 
>> need to say "0 is a reserved value that means in ospf virtual link case that 
>> the field is not semantically valid and in other cases represents value of 
>> 0" (which seems nonsensical a bit but seems to aim towards what the errata 
>> tries to say) 
>> 2. fragmenting/non-fragmenting tunnels need be considered and explained in 
>> the errata. GRE can optionally fragment (but not in v6 case AFAIR except 
>> optionally for some wild header cases). In case of IPv6 we have additionally 
>> the 1280 consideration on top AFAIR so if parts of the network runs bigger 
>> MTU, GRE does NOT fragment and more than 1280 shows up we end up with 
>> fragmented network IGP wise possibly. And I didn't even start to talk about 
>> extension headers on which the RFC is really quiet about  ;-) 
>> 3. the MTU "largest datagram" needs to be errate'd to something more precise 
>> on top. Is that _with_ tunnel headers, with/without tunnel encaps etc 
>> (observe that e.g. vxlan is really an ip in ip and then ospf could be 
>> carried in that) or _purely_ the OSPF IPv6 packet? 
>> 
>> we fought those problems in ISIS forever with ugly corner cases (PPoE) I 
>> need to explain every couple of years to another batch of system engineers .
>> 
>> I personally strongly suggest from experience to say "0 value" semantics is 
>> everywhere a "don't care" value which implicitly does remove MTU mismatch 
>> considerations in all kinds of interesting, ugly deployment cases. Other 
>> option is that to mean "same value as set on my interface" or "default value 
>> the protocol has set as constant" (in rift we chose that route from 
>> experience but we were driven by strong ZTP requirements) 
>> 
>> And BTW, any hardened stack has "ignore-mtu-mismatch" since this is a pretty 
>> common case to find implementations advertising mismatched values in weird 
>> tunnel/encaps cases (VLAN taggin' cases are a classic culprit beside PPoE 
>> IME) and stuff gets knob'ed out then ... 
>> 
>> that's of top of my head here ... 
>> 
>> -- tony  
>> 
>> On Wed, Sep 20, 2023 at 8:06 PM Acee Lindem  wrote:
>> 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-editor.org/errata/eid7649
>> > 
>> > --
>> > Type: Technical
>> > Reported by: Owen DeLong 
>> > 
>> > Section: A.3.3 (in part)
>> > 
>> > Original Text
>> > -
>> > Interface MTU
>> >  The size in bytes of the largest IPv6 datagram that can be sent
>> >  out the associated interface without fragmentation.  The MTUs of
>> >  common Internet link types can be found in Table 7-1 of [MTUDISC].
>> >  Interface MTU should be set to 0 in Database Description packets
>> >  sent over virtual links.
>> > 
>> > 
>> > Corrected Text
>> > --
>> > Interface MTU
>> >  The size in bytes of the largest IPv6 datagram that can be sent
>> >  out the associated interface without fragmentation.  The MTUs of
>> >  common Internet link types can be found in Table 7-1 of [MTUDISC].
>> >  Interface MTU should be set to 0 in Database Description packets
>> >  sent over OSPF virtual links. This rule should not be applied to 
>> > tunnel
>> >  or other software interfaces.
>> > 
>> > Notes
>> > -
>> > OSPF Virtual links carry only OSPF packets so MTU negotiation is not 
>> > needed and this provision makes sense. For interfaces that have an actual 
>> > MTU, even though they may be "virtual" interfaces, they are not "virtual 
>> > links" in the intended meaning of this paragraph. As such, this change 
>> > will provide clarification and remove ambiguity from the current standard. 
>> > At least one popular router vendor implements this RFC as MTU = 0 sent on 
>> > all GRE interfaces which results in incompatibilities with most 

Re: [Lsr] [Technical Errata Reported] RFC5340 (7649)

[Owen DeLong]

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 
> 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 consideration applies AFAIS. So the errata would 
> need to say "0 is a reserved value that means in ospf virtual link case that 
> the field is not semantically valid and in other cases represents value of 0" 
> (which seems nonsensical a bit but seems to aim towards what the errata tries 
> to say) 
> 2. fragmenting/non-fragmenting tunnels need be considered and explained in 
> the errata. GRE can optionally fragment (but not in v6 case AFAIR except 
> optionally for some wild header cases). In case of IPv6 we have additionally 
> the 1280 consideration on top AFAIR so if parts of the network runs bigger 
> MTU, GRE does NOT fragment and more than 1280 shows up we end up with 
> fragmented network IGP wise possibly. And I didn't even start to talk about 
> extension headers on which the RFC is really quiet about  ;-) 
> 3. the MTU "largest datagram" needs to be errate'd to something more precise 
> on top. Is that _with_ tunnel headers, with/without tunnel encaps etc 
> (observe that e.g. vxlan is really an ip in ip and then ospf could be carried 
> in that) or _purely_ the OSPF IPv6 packet? 
> 
> we fought those problems in ISIS forever with ugly corner cases (PPoE) I need 
> to explain every couple of years to another batch of system engineers .
> 
> I personally strongly suggest from experience to say "0 value" semantics is 
> everywhere a "don't care" value which implicitly does remove MTU mismatch 
> considerations in all kinds of interesting, ugly deployment cases. Other 
> option is that to mean "same value as set on my interface" or "default value 
> the protocol has set as constant" (in rift we chose that route from 
> experience but we were driven by strong ZTP requirements) 
> 
> And BTW, any hardened stack has "ignore-mtu-mismatch" since this is a pretty 
> common case to find implementations advertising mismatched values in weird 
> tunnel/encaps cases (VLAN taggin' cases are a classic culprit beside PPoE 
> IME) and stuff gets knob'ed out then ... 
> 
> that's of top of my head here ... 
> 
> -- tony  
> 
> On Wed, Sep 20, 2023 at 8:06 PM Acee Lindem  > wrote:
>> 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-editor.org/errata/eid7649
>> > 
>> > --
>> > Type: Technical
>> > Reported by: Owen DeLong mailto:o...@delong.com>>
>> > 
>> > Section: A.3.3 (in part)
>> > 
>> > Original Text
>> > -
>> > Interface MTU
>> >  The size in bytes of the largest IPv6 datagram that can be sent
>> >  out the associated interface without fragmentation.  The MTUs of
>> >  common Internet link types can be found in Table 7-1 of [MTUDISC].
>> >  Interface MTU should be set to 0 in Database Description packets
>> >  sent over virtual links.
>> > 
>> > 
>> > Corrected Text
>> > --
>> > Interface MTU
>> >  The size in bytes of the largest IPv6 datagram that can be sent
>> >  out the associated interface without fragmentation.  The MTUs of
>> >  common Internet link types can be found in Table 7-1 of [MTUDISC].
>> >  Interface MTU should be set to 0 in Database Description packets
>> >  sent over OSPF virtual links. This rule should not be applied to 
>> > tunnel
>> >  or other software interfaces.
>> > 
>> > Notes
>> > -
>> > OSPF Virtual links carry only OSPF packets so MTU negotiation is not 
>> > needed and this provision makes sense. For interfaces that have an actual 
>> > MTU, even though they may be "virtual" interfaces, they are not "virtual 
>> > links" in the intended meaning of this paragraph. As such, this change 
>> > will provide clarification and remove ambiguity from the current standard. 
>> > At least one popular router vendor implements this RFC as MTU = 0 sent on 
>> > all GRE interfaces which results in incompatibilities with most other 
>> > router platforms which expect an actual value. The router vendor points to 
>> > this provision in the RFCs as justification for their implementation. It 
>> > is (arguably) a legitimate, if nonsensical interpretation of the existing 
>> > text.
>> > 
>> > Instructions:
>> > -

Re: [Lsr] [Technical Errata Reported] RFC5340 (7649)

[Robert Raszuk]

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 virtual link" hence it
seems this is a clear overinterpretation of the RFC.

I don't think either -bis is needed, nor errata.

Thx,
R.







On Wed, Sep 20, 2023 at 9:59 PM Acee Lindem  wrote:

> 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 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 to do a bis or an update. See also
> https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/
> >
> > —John
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Technical Errata Reported] RFC5340 (7649)

[Acee Lindem]

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 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 to do a bis or an update. See also 
> https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/
> 
> —John


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Technical Errata Reported] RFC5340 (7649)

[John Scudder]

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 to do a bis or an update. See also 
https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/

—John
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Technical Errata Reported] RFC5340 (7649)

[Tony Przygienda]

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 consideration applies AFAIS. So the
errata would need to say "0 is a reserved value that means in ospf virtual
link case that the field is not semantically valid and in other cases
represents value of 0" (which seems nonsensical a bit but seems to aim
towards what the errata tries to say)
2. fragmenting/non-fragmenting tunnels need be considered and explained in
the errata. GRE can optionally fragment (but not in v6 case AFAIR except
optionally for some wild header cases). In case of IPv6 we have
additionally the 1280 consideration on top AFAIR so if parts of the network
runs bigger MTU, GRE does NOT fragment and more than 1280 shows up we end
up with fragmented network IGP wise possibly. And I didn't even start to
talk about extension headers on which the RFC is really quiet about  ;-)
3. the MTU "largest datagram" needs to be errate'd to something more
precise on top. Is that _with_ tunnel headers, with/without tunnel encaps
etc (observe that e.g. vxlan is really an ip in ip and then ospf could be
carried in that) or _purely_ the OSPF IPv6 packet?

we fought those problems in ISIS forever with ugly corner cases (PPoE) I
need to explain every couple of years to another batch of system engineers .

I personally strongly suggest from experience to say "0 value" semantics is
everywhere a "don't care" value which implicitly does remove MTU mismatch
considerations in all kinds of interesting, ugly deployment cases. Other
option is that to mean "same value as set on my interface" or "default
value the protocol has set as constant" (in rift we chose that route from
experience but we were driven by strong ZTP requirements)

And BTW, any hardened stack has "ignore-mtu-mismatch" since this is a
pretty common case to find implementations advertising mismatched values in
weird tunnel/encaps cases (VLAN taggin' cases are a classic culprit beside
PPoE IME) and stuff gets knob'ed out then ...

that's of top of my head here ...

-- tony

On Wed, Sep 20, 2023 at 8:06 PM Acee Lindem  wrote:

> 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-editor.org/errata/eid7649
> >
> > --
> > Type: Technical
> > Reported by: Owen DeLong 
> >
> > Section: A.3.3 (in part)
> >
> > Original Text
> > -
> > Interface MTU
> >  The size in bytes of the largest IPv6 datagram that can be sent
> >  out the associated interface without fragmentation.  The MTUs of
> >  common Internet link types can be found in Table 7-1 of [MTUDISC].
> >  Interface MTU should be set to 0 in Database Description packets
> >  sent over virtual links.
> >
> >
> > Corrected Text
> > --
> > Interface MTU
> >  The size in bytes of the largest IPv6 datagram that can be sent
> >  out the associated interface without fragmentation.  The MTUs of
> >  common Internet link types can be found in Table 7-1 of [MTUDISC].
> >  Interface MTU should be set to 0 in Database Description packets
> >  sent over OSPF virtual links. This rule should not be applied to
> tunnel
> >  or other software interfaces.
> >
> > Notes
> > -
> > OSPF Virtual links carry only OSPF packets so MTU negotiation is not
> needed and this provision makes sense. For interfaces that have an actual
> MTU, even though they may be "virtual" interfaces, they are not "virtual
> links" in the intended meaning of this paragraph. As such, this change will
> provide clarification and remove ambiguity from the current standard. At
> least one popular router vendor implements this RFC as MTU = 0 sent on all
> GRE interfaces which results in incompatibilities with most other router
> platforms which expect an actual value. The router vendor points to this
> provision in the RFCs as justification for their implementation. It is
> (arguably) a legitimate, if nonsensical interpretation of the existing text.
> >
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --
> > RFC5340 (draft-ietf-ospf-ospfv3-update-23)
> > --
> > Title   : OSPF for IPv6
> > Publication Date: July 2008
> > Author(s)   : R. Coltun, D. 

Re: [Lsr] [Technical Errata Reported] RFC5340 (7649)

[Acee Lindem]

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-editor.org/errata/eid7649
> 
> --
> Type: Technical
> Reported by: Owen DeLong 
> 
> Section: A.3.3 (in part)
> 
> Original Text
> -
> Interface MTU
>  The size in bytes of the largest IPv6 datagram that can be sent
>  out the associated interface without fragmentation.  The MTUs of
>  common Internet link types can be found in Table 7-1 of [MTUDISC].
>  Interface MTU should be set to 0 in Database Description packets
>  sent over virtual links.
> 
> 
> Corrected Text
> --
> Interface MTU
>  The size in bytes of the largest IPv6 datagram that can be sent
>  out the associated interface without fragmentation.  The MTUs of
>  common Internet link types can be found in Table 7-1 of [MTUDISC].
>  Interface MTU should be set to 0 in Database Description packets
>  sent over OSPF virtual links. This rule should not be applied to tunnel
>  or other software interfaces.
> 
> Notes
> -
> OSPF Virtual links carry only OSPF packets so MTU negotiation is not needed 
> and this provision makes sense. For interfaces that have an actual MTU, even 
> though they may be "virtual" interfaces, they are not "virtual links" in the 
> intended meaning of this paragraph. As such, this change will provide 
> clarification and remove ambiguity from the current standard. At least one 
> popular router vendor implements this RFC as MTU = 0 sent on all GRE 
> interfaces which results in incompatibilities with most other router 
> platforms which expect an actual value. The router vendor points to this 
> provision in the RFCs as justification for their implementation. It is 
> (arguably) a legitimate, if nonsensical interpretation of the existing text.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC5340 (draft-ietf-ospf-ospfv3-update-23)
> --
> Title   : OSPF for IPv6
> Publication Date: July 2008
> Author(s)   : R. Coltun, D. Ferguson, J. Moy, A. Lindem
> Category: PROPOSED STANDARD
> Source  : Open Shortest Path First IGP
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] [Technical Errata Reported] RFC5340 (7649)

[RFC Errata System]

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 (in part)

Original Text
-
Interface MTU
  The size in bytes of the largest IPv6 datagram that can be sent
  out the associated interface without fragmentation.  The MTUs of
  common Internet link types can be found in Table 7-1 of [MTUDISC].
  Interface MTU should be set to 0 in Database Description packets
  sent over virtual links.


Corrected Text
--
Interface MTU
  The size in bytes of the largest IPv6 datagram that can be sent
  out the associated interface without fragmentation.  The MTUs of
  common Internet link types can be found in Table 7-1 of [MTUDISC].
  Interface MTU should be set to 0 in Database Description packets
  sent over OSPF virtual links. This rule should not be applied to tunnel
  or other software interfaces.

Notes
-
OSPF Virtual links carry only OSPF packets so MTU negotiation is not needed and 
this provision makes sense. For interfaces that have an actual MTU, even though 
they may be "virtual" interfaces, they are not "virtual links" in the intended 
meaning of this paragraph. As such, this change will provide clarification and 
remove ambiguity from the current standard. At least one popular router vendor 
implements this RFC as MTU = 0 sent on all GRE interfaces which results in 
incompatibilities with most other router platforms which expect an actual 
value. The router vendor points to this provision in the RFCs as justification 
for their implementation. It is (arguably) a legitimate, if nonsensical 
interpretation of the existing text.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC5340 (draft-ietf-ospf-ospfv3-update-23)
--
Title   : OSPF for IPv6
Publication Date: July 2008
Author(s)   : R. Coltun, D. Ferguson, J. Moy, A. Lindem
Category: PROPOSED STANDARD
Source  : Open Shortest Path First IGP
Area: Routing
Stream  : IETF
Verifying Party : IESG

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr