Re: [OSPF] OSPF WG Minutes from IETF 95

["Acee Lindem (acee)" <[e-mail]>]

On 4/14/16, 10:58 AM, "Paul Jakma" <[e-mail]> wrote:

>On Wed, 13 Apr 2016, Acee Lindem (acee) wrote:
>
>> One of the authors or myself will write an errata to clarify this
>> definition.
>
>Great. :)
>
>> But the OSPF stub router functionality is achieved using 0xffff, so
>> your proposal is NOT backward compatible.
>
>Why not?
>
>Any sufficiently large metric (relative to the cost of the longest path
>in the network) will induce the desired "transit is still fine"
>behaviour in the stub-router RFC.
>
>It turns out the 0xffff metric was never intended to be special by that
>RFC - or we wouldn't be having this discussion. It _not_ intended to
>change SPF behaviour. So, how could using a lower value cause
>compatibility issues? ??

Using 0xfffe, in itself, will not cause backward compatibility problems.
However, you’ll still have backward compatibility issues as long as the
interpretation of 0xffff varies between router in the OSPF routing domain.
In reading the rest of this E-mail, I believe this is well understood.

>
>> The reality is that the standards WILL NOT change to match your
>> interpretation.
>
>Well, not asking you to. ;)
>
>I'm just saying Quagga has been shipping for years with "0xffff link
>metric means its SPF will not follow such a link out of a router when
>calculating the SPF tree" behaviour. The reason was provide the
>"absolutely no-transit" type behaviour (as "discouraged, but transit is
>still OK" behaviour is achievable with many other metrics).
>
>I'm not arguing for anything, I'm just saying the existence of such
>implementations is a reality.
>
>For Quagga, it seems the best way forward is:
>
>- As/when H-bit clearly is going to be a standard, Quagga can use H-bit
>   + 0xffff link metrics to signal "absolutely no transit", when the
>   administrator desires that behaviour.
>
>   * This will have the desired effect with all routers that recognise
>     the H-bit, and all Quagga
>
>- If the administrator wants "discourage, but transit still OK" then
>   Quagga will just set some large, non-0xffff metric in the links (e.g.
>   0xfffe).
>
>   * This will have the desired effect with all routers, Quagga old and
>     new, RFC2328, pre-1583, etc., without any issues (AFAIK).
>
>That seems the best thing we can do.
>
>It leaves other cases where things might not quite be consistent. For
>those there'll be an admin option to control the SPF-0xffff-transit
>behaviour between the longish-standing Quagga "no-transit" behaviour and
>1583/2328. That will probably have to default to the "no-transit"
>behaviour for a while longer, but in time hopefully flip it over to
>2328.

This sounds like a good plan.

Thanks,
Acee 




>
>regards,
>-- 
>Paul Jakma	[e-mail]	@pjakma	Key ID: 64A2FF6A
>Fortune:
>Given sufficient time, what you put off doing today will get done by
>itself.