Subject: [OSPF] Unnumbered PtoP router LSA question.

From: "Joakim Tjernlund" <[email-masked]>
Date: Tue, 6 Jan 2009 17:18:46 +0100

In RFC 2328, Chap 12.4.1.1, reads:
            12.4.1.1.  Describing point-to-point interfaces

                For point-to-point interfaces, one or more link
                descriptions are added to the router-LSA as follows:

                o   If the neighboring router is fully adjacent, add a
                    Type 1 link (point-to-point). The Link ID should be
                    set to the Router ID of the neighboring router. For
                    numbered point-to-point networks, the Link Data
                    should specify the IP interface address. For
                    unnumbered point-to-point networks, the Link Data
                    field should specify the interface's MIB-II [Ref8]
                    ifIndex value. The cost should be set to the output
                    cost of the point-to-point interface.

                o   In addition, as long as the state of the interface
                    is "Point-to-Point" (and regardless of the
                    neighboring router state), a Type 3 link (stub
                    network) should be added. There are two forms that
                    this stub link can take:

                    Option 1
                        Assuming that the neighboring router's IP
                        address is known, set the Link ID of the Type 3
                        link to the neighbor's IP address, the Link Data
                        to the mask 0xffffffff (indicating a host
                        route), and the cost to the interface's
                        configured output cost.[15]

                    Option 2
                        If a subnet has been assigned to the point-to-
                        point link, set the Link ID of the Type 3 link
                        to the subnet's IP address, the Link Data to the
                        subnet's mask, and the cost to the interface's
                        configured output cost.[16]

I have a hard time figuring out what to do with Option 1 and Option 2 for unnumbered
PtoP interfaces. I don't think either of them applies to an unnumbered link so
I wonder if one should omit both Options?
However 12.4.1.1 starts with:
   For point-to-point interfaces, one or more link
   descriptions are added to the router-LSA as follows

which could be read as there must always be one or more items and as the first
item needs to have a fully adjacent router you could end up with zero items in the LSA for
a PtoP interface.
So what should one do?

     Jocke

_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: Acee Lindem <[email-masked]>
Date: Tue, 6 Jan 2009 11:55:39 -0500

Hi Joakim,
While it certainly isn't described very well, the intent is that the  
second router link is omitted for unnumbered links. If you look at  
the example for RT3's backbone area router LSA on page 134, you'll  
note the omission.

  ; RT3's router-LSA for the backbone

         LS age = 0                     ;always true on origination
         Options = (E-bit)              ;
         LS type = 1                    ;indicates router-LSA
         Link State ID = 192.1.1.3      ;RT3's router ID
         Advertising Router = 192.1.1.3 ;RT3's router ID
         bit E = 0                      ;not an AS boundary router
         bit B = 1                      ;area border router
         #links = 1
                Link ID = 18.10.0.6     ;Neighbor's Router ID
                Link Data = 0.0.0.3     ;MIB-II ifIndex of P-P link
                Type = 1                ;connects to router
                # TOS metrics = 0
                metric = 8

I'll keep this in my list of RFC 2328 inaccuracies.

Thanks,
Acee

---

From: "Joakim Tjernlund" <[email-masked]>
Date: Tue, 6 Jan 2009 19:31:06 +0100

Hi Acee

Thanks for your quick answer. I have seen the example but I didn't think
an example was authorative. Can I trust this example and/or your statement
to be authorative?
Can I have your list of RFC 2328 inaccuracies?

   Jocke

> -----Original Message-----
> From: Acee Lindem [mailto:[email-masked]]
> Sent: den 6 januari 2009 17:56
> To: Joakim Tjernlund
> Cc: [email-masked]
> Subject: Re: [OSPF] Unnumbered PtoP router LSA question.
> 
> Hi Joakim,

---

From: Dave Katz <[email-masked]>
Date: Tue, 6 Jan 2009 11:46:33 -0700

The idea of Option 1 is to provide connectivity to the remote router  
itself.  The remote router has an address, and it is known to the  
local router as soon as the first Hello is received.  So by definition  
it is always possible to do (since the remote router's address must be  
known in order to have an adjacency in the first place.)

One could claim that it would make more sense for a router to announce  
its *own* address in a link, and in fact some implementations do so  
gratuitously for safety's sake.  Or a loopback interface (with an  
independent address) is included in the OSPF configuration to achieve  
the same thing.  But without either Option 1 or one of the hacks, it  
may not be possible to address the router itself for management  
purposes.

So I would not suggest to omit the second link;  the inaccuracy is in  
the example instead.

--Dave

---

From: "Joakim Tjernlund" <[email-masked]>
Date: Tue, 6 Jan 2009 20:01:05 +0100

> From: Dave Katz [mailto:[email-masked]]
> Sent: den 6 januari 2009 19:47
> To: Joakim Tjernlund
> Cc: 'Acee Lindem'; [email-masked]

True, but that is addressed in footnote 2:
 [2]It is possible for all of a router's interfaces to be unnumbered
    point-to-point links.  In this case, an IP address must be assigned
    to the router.  This address will then be advertised in the router's
    router-LSA as a host route.

An related question: what to do with an interface that is UP but not RUNNING?

I would think that such an interface should be treated as a LoopBack interface
and so a host route should be announced. That would help to always have an address
to reach the router for management purposes.

---

From: Dave Katz <[email-masked]>
Date: Tue, 6 Jan 2009 12:20:59 -0700

>    router-LSA as a host route.

The footnote is sort of bogus on three counts.  First of all, a router  
*must* have an address somewhere, or it has nothing to put in the IP  
source address field, can't be managed, and is an incredibly expensive  
door stop.  So that bit is redundant.  Secondly, there is no explicit  
mechanism in the spec for advertising that host route, unless this  
sentence is intended to be normative (in which case the "will" should  
be a "SHALL".)  Thirdly, if implementations were to actually follow  
the other section you mention and do option 1, advertising that host  
route is unnecessary because all of the OSPF neighbors will know the  
address and advertise it themselves (roundabout, as mentioned earlier,  
but it works.)  And that footnote is much narrower than the case we  
are talking about, which is that of *any* unnumbered interface,  
regardless of whether there are other numbered interfaces or not.

> An related question: what to do with an interface that is UP but not  

Given that these terms are not well-defined, it's not possible to  
answer in a normative way.  Even in a non-normative, casual way, it's  
not clear to me what the actual difference is.  If the link does not  
pass packets, for whatever reason, OSPF will not come up, and traffic  
will not be passed to the nonfunctional link.  Whether that interface  
address is advertised by the offending router is an implementation  
decision, as it has no functional use other than as a management  
address.  For that matter, it is then immaterial as to whether the  
interface is "up" in any way or not, since there's no traffic going to  
that interface anyhow.  One could choose to advertise *all* interface  
addresses as host routes whether the interface is up or not, in case  
anybody is sending packets to those addresses from afar.  But this is  
usually done with loopback addresses, which become the "router  
address" for management purposes and are independent of any physical  
hardware.

--Dave

---

From: Acee Lindem <[email-masked]>
Date: Tue, 6 Jan 2009 15:41:01 -0500

Hi Joakim,

> an example was authorative. Can I trust this example and/or your  

I've worked on at least four commercial implementations and this is  
the way it is implemented in all of them.

> Can I have your list of RFC 2328 inaccuracies?

No - since it is an E-mail folder :^) You can scan the RFC errata.

http://www.rfc-editor.org/errata.php

Thanks,
Acee

---

From: "Joakim Tjernlund" <[email-masked]>
Date: Tue, 6 Jan 2009 22:19:21 +0100

> Sent: den 6 januari 2009 20:21
> To: Joakim Tjernlund
> door stop.  So that bit is redundant.

Obviously an IP address is needed, the key part is that the IP address
should be announced as an host route in the router LSA. 

>  Secondly, there is no explicit
> be a "SHALL".)

What mechanism do you need? It is an impl. detail how you specify
that IP address, if you need one. Will vs. shall is perhaps an error, I can't
say, but I don't think the language in Option 1 or Option 2 is any stronger.

> Thirdly, if implementations were to actually follow

You only have do this iff you just have unnumbered interfaces, no need
to add an extra host route if you already announce one.

> address" for management purposes and are independent of any physical

The IP address on that link is still reachable through other interfaces. If you
have a connection to the router using its IP address, you can still use it
even if the interface isn't RUNNING(i.e someone pulled the cable for that interface).
So instead of removing the whole interface and its subnet from the OSPF domain, one
should change the router LSA to announce a host route with that interface's IP address.
That way you can have an router with one Ethernet interface that is always reachable
over any other(unnumbered) interface.

 Jocke

---

From: "Joakim Tjernlund" <[email-masked]>
Date: Tue, 6 Jan 2009 22:27:50 +0100

> Sent: den 6 januari 2009 21:41
> To: Joakim Tjernlund
> Cc: [email-masked]

OK, thanks. This will cut the size of the router LSA significantly when
you have many unnumbered interfaces. Also a lot of extra processing scanning
for "routes to self" from neighbors will go away.

> http://www.rfc-editor.org/errata.php

Searching for RFC 2328 only turns up one entry. Is that really all there
is? Maybe I am searching the wrong way?

   Jocke

---

From: Dave Katz <[email-masked]>
Date: Tue, 6 Jan 2009 16:34:35 -0700

> to add an extra host route if you already announce one.

I think we've gone in circles here.

If I understood your original posting, you were asking about the  
meaning/value of the options listed as part of 12.4.1.1.  The reason  
that they are there is to ensure reachability to the remote router  
itself, if it implements exactly what the spec says to do.  If the  
local router doesn't do Option 1, and the remote router only does  
exactly what the spec says to do, you will not be able to route to the  
remote router because nobody will announce reachability to its address.

One can look at the spec and say, "of course I should announce host  
routes for addresses I think the world might be interested in", and it  
will work, but the spec never actually says to do that, *except* in  
the case of a router with no numbered interfaces at all (and burying  
it in a footnote at the very end of the spec is not a terribly good  
thing even in that case.)

So a naïve implementor will still have a functional, reachable,  
manageable network if he implements Option 1 and doesn't advertise any  
host routes otherwise.  This is why Option 1 exists, and why it is  
normative.  If my box is neighbor to the the naïve implementor's box,  
and I don't do Option 1, and he doesn't have his loopback address or  
some other address outside of OSPF in a host route (perfectly in- 
spec), his box is going to be unreachable for management purposes.

Maybe I'm missing something here?

> should change the router LSA to announce a host route with that  

I guess I still don't understand the distinction between UP and  
RUNNING, but that's OK.  The point is (and I think we're in violent  
agreement) that if you want a router address to be reachable, it  
either has to be announced as a host route or as part of a subnet  
route.  If the interface isn't passing traffic, announcing a subnet  
route would be an exceedingly poor idea, so the host route is the way  
to go.  The spec is properly (IMHO) silent on when to send host routes  
in this case, as it is purely an implementation decision and is not  
subject to standardization.

> over any other(unnumbered) interface.

This is essentially independent of unnumbered interfaces.  The  
requirement for unnumbered interfaces is only that the source address  
in OSPF packets is reachable, so that the local router can send  
packets back to it.  The remote router can advertise host routes for  
any or all of its interface addresses if it wishes to, but in fact it  
doesn't need to advertise *any* host route for this to work, as the  
neighbor (by option 1) is required to advertise a host route on its  
behalf, which will draw traffic to the unnumbered interface.

If a router wishes to advertise host routes for interfaces so that  
management traffic may use them without worrying about the associated  
interface state, it can.  Note that this is no different than having  
functioning router interfaces that are not actually part of the OSPF  
domain (which is quite common.)

--Dave

---

From: Acee Lindem <[email-masked]>
Date: Tue, 6 Jan 2009 20:41:23 -0500

Hi Dave, Joakim,
The intent of the protocol is to not advertise stub links in router  
LSAs for unnumbered links. If one wishes to advertise the local  
address an unnumbered link is using, the interface should be  
configured as an OSPF interface.  Unfortunately, RFC 2328 section  
12.4.1.1 doesn't state this explicitly. Although I wasn't involved in  
the generation or review of RFC 2328, John Moy's public domain  
implementation (available at www.ospf.org) confirms this behavior and  
is consistent with most implementations - though possibly not all  
implementations.
Thanks,
Acee
On Jan 6, 2009, at 1:46 PM, Dave Katz wrote:

> The idea of Option 1 is to provide connectivity to the remote  
> router itself.  The remote router has an address, and it is known  
> to the local router as soon as the first Hello is received.  So by  
> definition it is always possible to do (since the remote router's  
> address must be known in order to have an adjacency in the first  
> place.)
>
> One could claim that it would make more sense for a router to  
> announce its *own* address in a link, and in fact some  
> implementations do so gratuitously for safety's sake.  Or a  
> loopback interface (with an independent address) is included in the  
> OSPF configuration to achieve the same thing.  But without either  
> Option 1 or one of the hacks, it may not be possible to address the  
> router itself for management purposes.
>
> So I would not suggest to omit the second link;  the inaccuracy is  
> in the example instead.
>
> --Dave
>
>
>

---

From: Dave Katz <[email-masked]>
Date: Tue, 6 Jan 2009 21:30:29 -0700

Well, *somebody* needs to advertise the address used as the source  
address for OSPF on unnumbered links, or the protocol will fail.  The  
spec specifically says that the receiver of said packets is supposed  
to advertise that address.  The spec does *not* say that the owner of  
that address should advertise it, as stupid as that may seem.

Speaking of intent is all well and good, but the spec has been out  
there for about 20 years now and it says something else.  John Moy's  
implementation is not the spec.

In reality, implementors seem to end up doing the right thing anyhow.   
(I still get grief for advertising the loopback address by default in  
our implementation, 11 years on, as that's not in the spec either.)   
But the spec, as written, works.  Simply ignoring Option 1 for  
unnumbered links *breaks the spec*.  Unless the spec is changed to  
specifically require that the address used as the source on unnumbered  
links is advertised in *some* LSA by the owner of said address, we  
cannot say that the clause as written is in error.

--Dave

On Jan 6, 2009, at 6:41 PM, Acee Lindem wrote:

> 12.4.1.1 doesn't state this explicitly. Although I wasn't involved  
> in the generation or review of RFC 2328, John Moy's public domain  
> implementation (available at www.ospf.org) confirms this behavior  
> and is consistent with most implementations - though possibly not  
> all implementations.
> Thanks,
> Acee

---

From: "Sean Andersen" <[email-masked]>
Date: Tue, 6 Jan 2009 21:55:04 -0800

There was a discussion about virtual links that kind of relates to this
discussion in a way. Although a virtual link through a stub area is not
applicable. 
I sent an email on that in 2003 and just found it in one of the archives
(link below)...hope it helps even though it may not be very closely related
to this discussion:
http://archives.neohapsis.com/archives/microsoft/various/ospf/2003-q1/0184.h
tml

Sean (Farshad)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave
Katz
Sent: Tuesday, January 06, 2009 8:30 PM
To: Acee Lindem
Cc: [email-masked]
Subject: Re: [OSPF] Unnumbered PtoP router LSA question.

--Dave

---

From: Joakim Tjernlund <[email-masked]>
Date: Wed, 07 Jan 2009 15:18:49 +0100

> spec), his box is going to be unreachable for management purposes.

I would not say that it is "perfectly in spec" as the spec actually
mentions this case explicitly in that footnote. I guess that the spec
assumes that it is very uncommon to just have unnumbered links is the
domain and that is perhaps why it is in a footnote.

Also I can can't find a reference in the spec that states that
the purpose of Option 1 is reachability, in [15] one can read: 
[15]This is the way RFC 1583 specified point-to-point
    representation.  It has three advantages: a) it does not require
    allocating a subnet to the point-to-point link, b) it tends to bias
    the routing so that packets destined for the point-to-point
    interface will actually be received over the interface (which is
    useful for diagnostic purposes) and c) it allows network
    bootstrapping of a neighbor, without requiring that the bootstrap
    program contain an OSPF implementation.

Further, looking into RFC 1583 one can see that Option 1 isn't used for
unnumbered links.

Also, there would be no need for footnote [2] if Option 1 is required
so why have in the first place?

Actully, the only thing that might suggest that Option 1 should be
used in 2328 is the text i Option 1 and that text is a bit "fuzzy".
Everything else suggests that Option 1 should not be used(in my reading)

> RUNNING, but that's OK.

Sorry, I should have explained this better. I refering to the
status of the interface as returned by ifconfig:
# > ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:06:9C:00:20:02  
          inet addr:10.0.1.1  Bcast:10.0.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

If I disconnect the ethernet cable, the RUNNING status goes away since
the interface cannot pass traffic on the ethernet, but the interface is
still UP.

What does Juniper do in this case for an interface that is part
of a OSPF area? I really like to find out how other routers handle
this case. 
 
> The point is (and I think we're in violent  

I think this is implicit in the spec. One can ask OSPF to announce
some subnets and all matching interfaces are then announced, if you pull
the cable, the IP address still matches and is reachable so it
should still be announced as a host route.   

 Jocke

---

From: Joakim Tjernlund <[email-masked]>
Date: Wed, 07 Jan 2009 18:30:24 +0100

> that address should advertise it, as stupid as that may seem.

Does it really have to be the source address used by the unnumbered
links? Isn't it enough to add any IP address used on the router?
So if you have at least one numbered interface in the area, you are
good.
If not, you will add a host route as footnote 2 says, usally done
with a loopback or dummy interface.

> In reality, implementors seem to end up doing the right thing anyhow.

Which ones(besides Juniper)? According to Acee at least 4 commercial
vendors does not.

> cannot say that the clause as written is in error.

The spec is fuzzy, for instance it says 
"a Type 3 link (stub network) should be added"
"Should" isn't very strict and the text in Option 1 is also
a bit fuzzy so I would not say that omitting Option 1 breaks
the spec even in its current form.

That said, I really think an official statement from IETF is
needed. Otherwise this issue will haunt OSPF for years to come.

 Jocke

---

From: Richard Ogier <[email-masked]>
Date: Wed, 07 Jan 2009 20:25:29 -0800

>Everything else suggests that Option 1 should not be used(in my reading)

I have found this discussion interesting and educational.
The above argument is very convincing, which I guess is why nobody
is arguing against it.  Based on the discussion, I think RFC 2328 should
be clarified as follows to allow some flexibility while ensuring
interoperability between different implementations (including most
existing implementations).

- Footnote [2] MUST be implemented, i.e., if all of the router's interfaces
  are point-to-point links, then the router's IP address MUST be advertised
  in the router-LSA as a host route.

- For unnumbered point-to-point links, a Type 3 link (stub network)
  MAY be added to the router-LSA (Option 1), but is not required.  Although
  adding such links may seem redundant, it has the benefit of ensuring that
  routes calculated to each router are *shortest* paths.  Without adding the
  stub links, the calculated routing table will provide the shortest path to
  each network and host, but that need not result in the shortest path to a
  router that is not advertising its own IP address as a host route.
  For example, the last hop of the shortest path might be via an unnumbered
  point-to-point link, but the last hop of the calculated path might be
  via a numbered point-to-point link (which includes a stub link to the
  destination router).  Let me know if I am mistaken.

Richard

---

From: Dave Katz <[email-masked]>
Date: Wed, 7 Jan 2009 22:06:52 -0700

> with a loopback or dummy interface.

The source address must be advertised somewhere (either as a host  
route or as part of a subnet route) or OSPF will fail;  any unicast  
OSPF packets (such as retransmissions) will not be deliverable  
otherwise.

> Which ones(besides Juniper)? According to Acee at least 4 commercial

I've long since lost track of what the "right thing" is.  ;-)  But  
there is an existence proof that unnumbered links work, so somebody is  
doing something right.  Unless somebody changed it since I wrote it,  
the Juniper box advertises the neighbor's address (according to option  
1) as well as its own as necessary.  Note that there's nothing harmful  
in implementing both belts and suspenders here.

> the spec even in its current form.

Well, don't get me started on the form of the OSPF spec.  It predates  
the MUST/SHALL/SHOULD language, is incredibly fuzzy on what's  
normative and what's not, never explains most of why it does what it  
does, and is at least as much an implementation guide as a protocol  
spec.  The good news is that you cannot build a scalable  
implementation by doing what the spec says to do;  if it didn't hand  
implementors a guide, they might actually have to think about it, and  
those of us with industrial-scale implementations might have more  
competition...

But it is the case that if you don't do Option 1, and your neighbor  
does not advertise a host route for its source address, the protocol  
will *not* work and thus the spec would be broken.

> needed. Otherwise this issue will haunt OSPF for years to come.

The problem is that there are 20 years of implementations out there,  
so any change whatsoever that is not backward compatible is arguably a  
non-starter.  Discussing the issue and offering belts to go with  
suspenders is not a bad thing, however.

--Dave

---

From: Dave Katz <[email-masked]>
Date: Wed, 7 Jan 2009 22:30:07 -0700

> in the router-LSA as a host route.

If all the router's interfaces are *unnumbered* point-to-point links.   
This is, for the most part, an uninteresting degenerate case and  
doesn't apply to the broader problem here, which is who should be  
advertising the source address of OSPF packets sent on *any*  
unnumbered link, independent of what the other link types are.

> destination router).  Let me know if I am mistaken.

This is presumably what the dreaded Option 1 attempted to do.  It  
attracts traffic to the neighbor router, which will then resolve the  
last hop to the unnumbered link itself via the usual mechanisms for  
directly-connected neighbors.  Of course, this only results in optimal  
routing if *all* of the links are unnumbered (so all of the neighbors  
are injecting the stub), but then footnote 2 kicks in and saves the  
day in the only case that actually works optimally.

You are right that the only way to get optimal routing to the router  
in the general case is for the router itself to advertise a stub.

I fail to see what's controversial about Option 1, save for the fact  
that it's suboptimal and a stupid way of solving the problem (rather  
than having the router owning the address advertise the route instead  
of its neighbors) and for the colloquial use of "should", which I  
always read as MUST in the more modern dialect.  To me it is  
straightforwardly and unambiguously required for unnumbered links  
(just as Option 2 is required for subnetted links.)  Other than  
substituting MUST for "should" I don't see any question about this.   
It is brain-dead six ways from Sunday (like a number of things in  
OSPF) but I think we're stuck with it due to backward compatibility  
issues.

Unfortunately, I doubt there is no IETF equivalent of the Federalist  
Papers to try to give hints of the true intentions of the framers.  (I  
was there, but didn't take notes, and was more interested in ISIS at  
the time anyhow.)  As soon as we figure out what the 2nd Amendment was  
for, we can go on to Option 1.  ;-)

--Dave

---

From: Richard Ogier <[email-masked]>
Date: Wed, 07 Jan 2009 22:57:17 -0800

Dave Katz wrote:

> If all the router's interfaces are *unnumbered* point-to-point 
> links.   This is, for the most part, an uninteresting degenerate case 
> and  doesn't apply to the broader problem here, which is who should 
> be  advertising the source address of OSPF packets sent on *any*  
> directly-connected neighbors.  Of course, this only results in 
> optimal  routing if *all* of the links are unnumbered (so all of the 
> neighbors  are injecting the stub), but then footnote 2 kicks in and 
> saves the  day in the only case that actually works optimally.

I am assuming that a stub link is always required for *numbered* 
point-to-point links (as per RFC 2328), and is optional for *unnumbered* 
links (my suggestion).  So this allows optimal routing even if only some 
of the links are unnumbered, by allowing Option 1 to be used for all 
point-to-point links.  (Maybe I wasn't clear about this.)    My point is 
that some people might think it is redundant to advertise stub links for 
unnumbered links, but there is a benefit - optimal routing to all routers.

In addition, Footnote 2 is required to ensure interoperability with 
routers that decide not to use Option 1 for unnumbered links.  The 
resulting clarification to RFC 2328 allows optimal routing to all 
routers (optionally), while hopefully complying with almost all existing 
implementations.  Let me know if I am mistaken.

Richard

> Papers to try to give hints of the true intentions of the framers.  
> (I  was there, but didn't take notes, and was more interested in ISIS 
> at  the time anyhow.)  As soon as we figure out what the 2nd Amendment 
> was  for, we can go on to Option 1.  ;-)
>
> --Dave
>
>

---

From: Richard Ogier <[email-masked]>
Date: Thu, 08 Jan 2009 09:04:57 -0800

I have an additional comment below.  (My last comment is also repated 
below.)

> in the general case is for the router itself to advertise a stub.

Yes, another way to ensure optimal routing to all routers is to have 
every router advertise its IP address as a stub link.  Obviously, this 
can also be done optionally if optimal routing is desired.  Therefore, 
my suggested clarification of RFC 2328 can be summarized as follows:

- Footnote 2 MUST be implemented.
- Option 1 is optional for unnumbered point-to-point links.
- Any router MAY advertise its IP address as a stub link, to ensure 
optimal routing.

> OSPF) but I think we're stuck with it due to backward compatibility  

Since Footnote 2 was already required by RFC 2328 (and hopefully your 
implementations are compliant with this), then making Option 1 optional 
for unnumbered links is backward compatible, even if you interpreted the 
RFC to require Option 1 for unnumbered links (which as Acee stated was 
not the intention.)   Let me know if I am mistaken.

Richard

---

From: Richard Ogier <[email-masked]>
Date: Thu, 08 Jan 2009 12:40:27 -0800

Jocke,

Here is one more piece of evidence (to add to your already convincing
evidence below), which makes it clear that stub links are required
for point-to-point links only when interface addresses are assigned.
The following is from RFC 2328, page 15.

   "Interfaces to point-to-point networks need
   not be assigned IP addresses.  When interface addresses are
   assigned, they are modelled as stub links, with each router
   advertising a stub connection to the other router's interface
   address. Optionally, an IP subnet can be assigned to the point-
   to-point network. In this case, both routers advertise a stub
   link to the IP subnet, instead of advertising each others' IP
   interface addresses."

There is no longer any doubt in my mind about this.  The main
clarification is that Footnote 2 MUST be implemented.
One can always add stub links that are not required.

Richard

---

From: "Joakim Tjernlund" <[email-masked]>
Date: Fri, 9 Jan 2009 00:08:12 +0100

Sorry for being a bit late, work has been chaotic ...

> Sent: den 8 januari 2009 06:07
> To: [email-masked]
> Cc: Acee Lindem; [email-masked]

This I don't understand, why can't it be any address on the router?

[SNIP]
> will *not* work and thus the spec would be broken.

I see why you need to announce a host route from the neighbor
but I don't understand why it has to the same IP address used for the
PtoP link.

You asked earlier why I wanted to drop Option 1 for unnumbered links, it is
mostly because I think I it can  have an impact on OSPF performance. Consider
a OSPF area with almost only PtoP links, adding Option 1  makes the Router LSA 
almost twice as big and there will be lots of extra stub links 
to process for little use.

 Jocke

---

From: "Joakim Tjernlund" <[email-masked]>
Date: Fri, 9 Jan 2009 00:16:14 +0100

> From: Richard Ogier [mailto:[email-masked]]
> Sent: den 8 januari 2009 21:40

Thanks

I do think however that Dave has a point. There are probably impl.
out there that does Option 1, but does not include a host route
to itself. Such routers will probably have a hard time working
with an router not doing Option 1.
I suspect that footnote 2 isn't enough, one must announce an host
route as soon as one have 1 or more unnumbered links.

 Jocke

---

From: Richard Ogier <[email-masked]>
Date: Thu, 08 Jan 2009 16:16:05 -0800

>route as soon as one have 1 or more unnumbered links.

If your suspicion is correct that Footnote 2 isn't enough, then that
would be an error in RFC 2328, since as we seem to agree, the RFC
does not require doing Option 1 for unnumbered links.

However, I am not sure your suspicion is correct.  Do you have an
example that shows Footnote 2 is not enough to ensure each router is
reachable?  I agree that if one wants to ensure *optimal* routes to
each router, then a router must announce a host route when it has 1
or more unnumbered links. (I can give an example to show this.)
But there is no requirement of optimal routes for management purposes.

Richard

---

From: Joakim Tjernlund <[email-masked]>
Date: Fri, 09 Jan 2009 10:46:41 +0100

> But there is no requirement of optimal routes for management purposes.

If I understand Dave correctly, the host route announced must be
the IP address used by the unnumbered PtoP links, I don't understand
this requirement though so I hope Dave is wrong.

Assuming Dave is wrong, and you just need some host route announced,
there is nothing I can see that forces OSPF to announce such route iff
there are other numbered interfaces too.

If it is enough with any route, such as an subnet from an Ethernet
interface, I believe most routers stops announcing this subnet if
the Ethernet cable is pulled.
I believe that if one pull the cable from an Ethernet interface, the
router should turn the announced subnet into a host route of type Loop
back instead, this is actually my next point I want to discuss
so any comments on this would be much appreciated.

   Jocke

---

From: Acee Lindem <[email-masked]>
Date: Fri, 9 Jan 2009 09:51:52 -0500

I agree that advertising the interface address being borrowed by IPv4  
unnumbered links is necessary for using that address as an endpoint  
for any IPv4 application (including OSPF virtual links). However, the  
protocol is not intended to so this automatically. Rather, that that  
interface should be configured to be advertised. Consider the case  
where you have many parallel unnumbered links between two routers -  
it makes much more sense for the unnumbered address to be advertised  
a single link than once for each unnumbered link.
Thanks,
Acee

---

From: Dave Katz <[email-masked]>
Date: Fri, 9 Jan 2009 10:40:25 -0500

> this requirement though so I hope Dave is wrong.

Actually, I'm wrong.  Most (probably all) implementations don't route  
their OSPF packets, but blast them out interfaces directly.  I got  
hung up on the fact that, without such an announcement, nobody could  
route to that source address, but it doesn't matter (typically).  Mea  
culpa.

> there are other numbered interfaces too.

True.

> the Ethernet cable is pulled.

Typically true.

> so any comments on this would be much appreciated.

And that's an implementation decision that should be outside the scope  
of the spec.

I'll fall on my sword here and say that there is no fundamental need  
to announce any router address by anybody unless the router wants to  
be reachable (a useful thing indeed, but not necessary to the  
functioning of the protocol.)

--Dave

---

From: Dave Katz <[email-masked]>
Date: Fri, 9 Jan 2009 11:10:12 -0500

On Jan 8, 2009, at 12:04 PM, Richard Ogier wrote:
> point-to-point links (as per RFC 2328), and is optional for  
> *unnumbered* links (my suggestion).

Hm, I guess a further ambiguity in the spec is the use of the word  
"option" in clause 12.4.1.1 (combined with the lower-case "should".)   
I always read "should" as MUST and "option" as a bullet point and  
implemented it as such.  English prose is a lousy way to specify a  
protocol without linguistic ground rules (eventually added by the  
IETF, but long after OSPF was created.)

But as I noted in my last email, I finally copped a clue and realized  
that Option 1 isn't required for the protocol to work.  Nor, for that  
matter, is option 2--since the link is point-to-point between two  
routers, there are no hosts there, and thus nothing that "must" be  
routed to, so the subnet route is pretty uninteresting.

But for that matter, footnote 2 is equally uninteresting from the  
standpoint of routing to hosts.  The language here seems to be as  
ambiguous as all the rest;  it says that the address "will then be  
advertised" which implies a normative clause elsewhere in the spec  
requiring such, but I don't see it.

Similarly, the text Richard quotes on page 15 is an introductory  
description of something for which there appears to be no normative  
text requiring it.

All of this gets back to the metaproblem, which is that the OSPF spec  
is incredibly muddled with regard to what is normative and what is  
not.  Although it may not be codified anywhere, the point of normative  
text in a spec is to ensure proper operation and interoperability of  
the protocol.  The fact is (contrary to my assertions earlier) that  
there is no requirement for *any* router address or point-to-point  
subnet to be announced in the protocol in order to ensure proper  
operation (providing reachability to hosts) or interoperability, with  
the sole exception of virtual link endpoints (which are accounted for  
in type 4 links anyhow.)

As being able to reach the router is rather useful, an implementation  
has an interest in advertising at least one way of reaching a router,  
but that is not truly necessary, and a router that did none of this  
would work just fine (assuming you had an out-of-band configuration  
mechanism, which is probably a lot safer security-wise, but that's a  
separate rant.)

But I withdraw my earlier rantings;  in fact none of this stub route  
stuff matters for interoperability and none of it should be  
normative.  A polite suggestion along the lines of "if you want to be  
able to reach the router in-band you'll need to advertise something to  
make that happen" as non-normative text would suffice.

Cleaning up the OSPF spec to make it rigorous along these lines is a  
thankless task that isn't likely to happen.  There have been a number  
of willful veerings from the spec on things that are unambiguously  
normative but stupid (like the 5 second rule for LSA generation *and*  
reception, and the 30 minute refresh interval) and can be ignored  
without impacting interoperability.

I'll shut up now...

--Dave

---

From: "Joakim Tjernlund" <[email-masked]>
Date: Fri, 9 Jan 2009 22:37:00 +0100

> Sent: den 9 januari 2009 16:40
> Cc: Richard Ogier; [email-masked]

OK, thanks for this.

> And that's an implementation decision that should be outside the scope

Could you comment on if you think a loopback host route is the
right think to announce or if once should use a plain stub host route?

Can you see any downsides announcing some type of host route
in this case?

 Jocke

---

From: Dave Katz <[email-masked]>
Date: Sat, 10 Jan 2009 09:56:19 -0500

> right think to announce or if once should use a plain stub host route?

The common thing is to create a loopback address that's independent of  
any interface, and to advertise that as a stub.  It provides a stable  
address over the long term, as interfaces and topology changes come  
and go.  In my original implementation, the Juniper box would  
automatically assign the lo0 address, if present, as the router ID,  
and in addition advertise a stub route to it.  Not sure if this is  
still the case (as I mentioned, some folks started complaining about  
this.)  This was also the endpoint address for BGP connections, which  
is the other primary use of routing to routers outside of management.

> Can you see any downsides announcing some type of host route

None that I know of;  it's pretty common.  It is one more link in the  
LSA, but if one more link creates performance problems, then the  
network/implementation has much bigger issues.

--Dave