Re: [OSPF] OSPF WG Minutes from IETF 95

[Paul Jakma <[e-mail]>]

Hi Alvaro,

On Thu, 14 Apr 2016, Alvaro Retana (aretana) wrote:

> Paul:
>
> Hi!
>
> You and I have had a similar conversation off-list...

Indeed, thanks for your help there. ;)

>> However, it is a fact that the behaviour desired by RFC6987 can be 
>> universally achieved with metrics of 0xfffe or lower. That was true 
>> before any misinterpretation, and is still true now.

> Both MaxLinkMetric and 0xfffe are "very large numbers" (VLN), which 
> means that if we use 0xfffe, or any other VLN (including 
> MaxLinkMetric), then we should get "the same" behavior.

> I wrote ""the same"" because the result can vary depending on which 
> VLN a router in the network uses with respect to another router that 
> may also want to be a stub.  For example, given 2 paths to a 
> destination, if a router uses 0xfffe (or any other VLN which is not 
> MaxLinkMetric) it should become a stub.  However, if a router on the 
> second path decides to use MaxLinkMetric, then the first one (the one 
> using 0xfffe) will become transit.  We can obviously expand that 
> example to n number of links and n values of VLN and end up with a 
> wide variety of results -- which will not be deterministic unless we 
> know which VLN each router used in each case...

Indeed.

However, this can happen with consistent use of 0xffff too. If both are 
0xffff, then a 3rd party router can still choose /either/ to route via, 
or both. Etc.

So, whether a router will or will not be used for transit will depend on 
the network topology, when a "transit is still OK" approach is still 
used.

Also, this does not take the original link-metric into account either, 
right? It could be that the links on the one path originally were 100 
the other 1000. Clearly, if both now go stub, you'd want 3rd parties to 
prefer the "originally 100" one, but that information is lost.

So, if this were a consideration, wouldn't it be better to do 
stub-router with a "Add X to existing cost of all the links" approach? 
Where X is larger than the largest path cost, but less than the 
difference to 0xffff?

> When we originally wrote rfc3137 (the precursor of rfc6987), we chose 
> MaxLinkMetric because it guarantees the stub behavior (no other VLN is 
> higher), unless an alternate path does not exist.  Clearly we took 
> advantage of how the metric is treated in the current OSPF 
> specification (starting with rfc1583).  If we has used 0xfffe (or any 
> other VLN) then the behavior wouldn't have been guaranteed (using the 
> current OSPF spec).

Ah, ok.

Though, you didn't want to guarantee a router wouldn't be used... and as 
above judging the cost of alternate paths gets tricky with... Anyway. ;)

>> 0xffff today will not universally be recognised as meaning "you can 
>> still calculate transit paths out of a router using that link". 
>> 0xfffe or below will.
>>
>> That is the reality today.
>
> True, but only for pre-rfc1583 routers.

Well, Quagga has treated 0xffff links as infinite / strictly-no-transit 
out of a vertex for 9 years now.

regards,
-- 
Paul Jakma	[e-mail]	@pjakma	Key ID: 64A2FF6A
Fortune:
"I don't think they could put him in a mental hospital.  On the other
hand, if he were already in, I don't think they'd let him out."