Subject: [OSPF] OSPF WG Minutes from IETF 95

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 10 Apr 2016 21:56:46 +0000

The minutes for are posted here:
https://www.ietf.org/proceedings/95/minutes/minutes-95-ospf

Thanks to Les Ginsberg from Cisco for taking them.

Note that there were two names that we were not sure of and they are
preceded with “(???)”. Please E-mail me if you know either of these full
names and I will update the minutes.

Thanks,
Acee

---

From: prz <[email-masked]>
Date: Mon, 11 Apr 2016 05:13:36 -0700

> names and I will update the minutes.

 hmm, reading minutes & grinning, wasn't that you that chided me on the 
 mike 2-3 IETFs ago
 with "by now since 10 years e'one got the max-link-metric stuff right" 
 ;-)

 Agree on the comment with the bandwidth encoding. No need to invent 
 another one.

 --- tony

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 11 Apr 2016 15:29:32 +0000

> with "by now since 10 years e'one got the max-link-metric stuff right"

I guess I underestimated the inherent fallibility of software produced by
homo sapiens ;^).

David Lamparter did some research and found that RFC 1247 (July, 1991)
actually had LSInfinity defined as a variable length constant:

LSInfinity
    The link state metric value indicating that the destination is
    unreachable.  It is defined to be the binary value of all ones.  It
    depends on the size of the metric field, which is 16 bits in router
    links advertisements, and 24 bits in both summary and AS external
    links advertisements.

Additionally, the link would not be used for transit traffic (section
16.1): 

    (d) If the cost of the link (from V to W) is LSInfinity, the link
        should not be used for data traffic.  In this case, examine the
        next link in the advertisement.

However, this was changed in RFC 1583 (March, 1994).

 LSInfinity
        The metric value indicating that the destination described by a
        link state advertisement is unreachable. Used in summary link
        advertisements and AS external link advertisements as an
        alternative to premature aging (see Section 14.1). It is defined
        to be the 24-bit binary value of all ones: 0xffffff.

If in 2016 (22 years later), one particular implementation chooses to not
comply to the specification, then there really isn’t anything the WG can
do about it. The draft
https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/ allows a
link to be used exclusively for non-transit traffic. Of course, if you
also didn’t want to use the link for any traffic you simply wouldn’t
advertise it. 

Thanks,
Acee

---

From: Paul Jakma <[email-masked]>
Date: Wed, 13 Apr 2016 15:08:08 +0100 (BST)

On Mon, 11 Apr 2016, Acee Lindem (acee) wrote:

> do about it.

Part of the issue here was that the stub-router RFC features language 
that is often used to indicate authoritative changes to behaviour:

"3.  Maximum Link Metric

     Section 2 refers to the cost of all non-stub links as MaxLinkMetric,
     which is a new fixed architectural value introduced in this
     document.

    MaxLinkMetric
       The metric value indicating that a router-LSA link (see Section 2)
       should not be used for transit traffic.  It is defined to be the
       16-bit binary value of all ones: 0xffff."

Note the "should not".

Given that just discouraging traffic but still allowing transit, doesn't 
require any special metric valie to be called out - any high metric will 
do, that's just normal behaviour of metrics; and given that having the 
means to be able to totally disallow transit is desirable (see R-bit in 
v3, and the H-bit)... It's then not at all impossible to think the above 
did intend to mean 0xffff to not allow transit.

> The draft 

That won't work, I think.

Other hosts won't have a backlink then, and won't be able to calculate a 
route to the host. The OSPF host may then be unreachable. That's 
qualitatively different from other hosts still being able to calculate a 
path to the host it self.

For the RFC6987 desired behaviour, any high metric other than 0xffff 
will universally work.

For "no transit, and I really mean it", Quagga will follow the H-bit as 
soon as it's clear it will be a standard.

regards,
-- 
Paul Jakma	[email-masked]	@pjakma	Key ID: 64A2FF6A
Fortune:
Small is beautiful.
 		-- Schumacher's Dictum

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 13 Apr 2016 15:24:32 +0000

>did intend to mean 0xffff to not allow transit.

Are you familiar with the requirements language? While the use of “should
not” is unfortunate, it is not normative. To be normative it would need to
be “SHOULD NOT”. Furthermore, RFC 6987 is informational as opposed to
standards track. Finally, the document goes on to precisely state the
behavior (refer to the last paragraph of section 4).

4.  Deployment Considerations

   When using MaxLinkMetric, some inconsistency may be seen if the
   network is constructed of routers that perform an intra-area Dijkstra
   calculation as specified in [RFC1247] (discarding link records in
   router-LSAs that have a MaxLinkMetric cost value) and routers that
   perform it as specified in [RFC1583] and higher (do not treat links
   with MaxLinkMetric cost as unreachable).  Note that this
   inconsistency will not lead to routing loops, because if there are
   some alternate paths in the network, both types of routers will agree
   on using them rather than the path through the stub router.  If the
   path through the stub router is the only one, the routers of the
   first type will not use the stub router for transit (which is the
   desired behavior), while the routers of the second type will still
   use this path.

   On the other hand, clearing the R-bit will consistently result in the
   router not being used for transit.

   The use of MaxLinkMetric or the R-bit in a network depends on the
   objectives of the operator.  One of the possible considerations for
   selecting one or the other is in the desired behavior if the path
   through the stub router is the only one available.  Using
   MaxLinkMetric allows for that path to be used while the R-bit
   doesn't.

I believe the above is clear.

>That won't work, I think.

Note that I said “didn’t want to use the link for any traffic.”

>For the RFC6987 desired behaviour, any high metric other than 0xffff

You have misinterpreted it.

Thanks,
Acee

---

From: Paul Jakma <[email-masked]>
Date: Wed, 13 Apr 2016 21:14:21 +0100 (BST)

On Wed, 13 Apr 2016, Acee Lindem (acee) wrote:

> Are you familiar with the requirements language? While the use of 
> “should not” is unfortunate, it is not normative. To be normative it 
> would need to be “SHOULD NOT”.

Capitals are not required. If one is used to RFC2328, one would not 
expect normative language to be shouty.

> Furthermore, RFC 6987 is informational as opposed to standards track.
> Finally, the document goes on to precisely state the behavior (refer 
> to the last paragraph of section 4).

> I believe the above is clear.

Sure, 4 reads the other way but "deployment considerations" . I'm not 
saying how it must be read, just saying it is possible to read the 
stronger language of 3 another way.

I'm not trying to argue, I'm trying to explain why we are here.

> You have misinterpreted it.

I may have misinterpreted RFC6987, sure.

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.

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.

regards,
-- 
Paul Jakma	[email-masked]	@pjakma	Key ID: 64A2FF6A
Fortune:
Even a blind pig stumbles upon a few acorns.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 13 Apr 2016 22:31:12 +0000

On 4/13/16, 4:14 PM, "Paul Jakma" <[email-masked]> wrote:

>Capitals are not required.

This is not my convention - please see RFC 2119.

>If one is used to RFC2328, one would not

>I'm not trying to argue, I'm trying to explain why we are here.

One of the authors or myself will write an errata to clarify this
definition. 

>before any misinterpretation, and is still true now.

But the OSPF stub router functionality is achieved using 0xffff, so your
proposal is NOT backward compatible.

>still calculate transit paths out of a router using that link".

There will always be software bugs and these should be corrected.

> 0xfffe 

See above - this is not backward compatible.

>That is the reality today.

The reality is that the standards WILL NOT change to match your
interpretation. If you want to change the standard, we look forward to
your proposal in draft form with backward compatibility for the
implementations with the correct interpretation.

Thanks,
Acee

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 14 Apr 2016 13:10:45 +0000

On 4/13/16, 4:14 PM, "OSPF on behalf of Paul Jakma" <[email-masked]
on behalf of [email-masked]> wrote:

[Speaking as WG participant and author of rfc6987.]

Paul:

Hi!

You and I have had a similar conversation off-list...

...
>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...

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).

>That is the reality today.

True, but only for pre-rfc1583 routers.

Regards,

Alvaro.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 14 Apr 2016 13:28:23 +0000

On 4/13/16, 6:31 PM, "OSPF on behalf of Acee Lindem (acee)"
<[email-masked] on behalf of [email-masked]> wrote:

<hat>author<hat>

Acee:

Hi!

>One of the authors or myself will write an errata to clarify this

What do you have in mind?

I may be too close to the text myself to tell where we should change
something.  Even if we interpret the "should not" in Section 3 as if it
was "SHOULD NOT", it is still not a "MUST"...and the obvious reason the
link would be used is if there isn't another path.

There is one part which I think can be clarified (only including the
change):

NEW>
4.  Deployment Considerations
...
   on using them rather than the path through the stub router.  If the
   path through the stub router is the only one, the routers of the
   first type will not use the stub router for transit, while the routers
   of the second type will still use this path, which may result in a
routing 
   loop.
...

I'm open to other suggestions.

Thanks!

Alvaro.

CURRENT TEXT>
3.  Maximum Link Metric

   Section 2 refers to the cost of all non-stub links as MaxLinkMetric,
   which is a new fixed architectural value introduced in this document.

   MaxLinkMetric
      The metric value indicating that a router-LSA link (see Section 2)
      should not be used for transit traffic.  It is defined to be the
      16-bit binary value of all ones: 0xffff.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 14 Apr 2016 13:40:07 +0000

<hat>Author of compliment implementation</hat>

Hi Alvaro, 

I don’t necessarily agree that the only case where the links with
MaxLinkMetric will be used is when there is no other path. One could have
a situation where an alternate path existed but the aggregate cost was
greater than 64K. I agree this is highly unlikely in real deployments but
very likely in test topologies. Hence, I’d leave the section 4 text as is
and modify the section 3 text.

   MaxLinkMetric
      The metric value indicating that a router-LSA link (see Section 2)
      should strongly discourage the usage for transit traffic.  It is
      defined to be the 16-bit binary value of all ones: 0xffff.

Thanks,
Acee

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 14 Apr 2016 14:52:12 +0000

On 4/14/16, 9:40 AM, "Acee Lindem (acee)" <[email-masked]> wrote:

Acee:

...
>...I¹d leave the section 4 text as is

I agree with your proposal.

The reason for proposing a change in 4 is because if only one path exists
it may result in a loop (if pre-rfc1583 and current routers are present):

<-- 0/0 -- rtr1 -- rtr2 -- rtr3 -- destination -->

In this network there's a default route going left and the destination we
want to reach is on the right.  rtr2 is a pre-rfc1583 router and rtr3 uses
rfc6987.

If the source is connected to rtr1, rtr1 will decide to use rtr3 as
transit (it is the only path).  But rtr2 will not and send the packet back
to rtr1 (following the default), resulting in a loop.

...so the text below clarifies that it is a possibility.

We can file these are independent errata and let the AD deal with them.
;-)  In both cases I think the update doesn't change the spirit of the RFC
and can just be help for document update.

Thanks!

Alvaro.

---

From: Paul Jakma <[email-masked]>
Date: Thu, 14 Apr 2016 15:58:09 +0100 (BST)

> One of the authors or myself will write an errata to clarify this

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? ??

> 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.

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

---

From: Paul Jakma <[email-masked]>
Date: Thu, 14 Apr 2016 16:20:39 +0100 (BST)

Hi Alvaro,

> You and I have had a similar conversation off-list...

Indeed, thanks for your help there. ;)

> 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?

> 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. ;)

>> 0xfffe or below will.

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

regards,
-- 
Paul Jakma	[email-masked]	@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."

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 15 Apr 2016 09:51:23 +0000

>change SPF behaviour. So, how could using a lower value cause

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.

>behaviour for a while longer, but in time hopefully flip it over to

This sounds like a good plan.

Thanks,
Acee