Subject: Re: Multiple un-numbered serial links between two routers

From: "Naidu, Venkata" <[email-masked]>
Date: Tue, 15 Apr 2003 14:07:28 -0400

-> I agree with Acee. I am not sure why we compulsarily need to
-> have multiple
-> parallel links between two routers advertized in the LSA,
-> for normal SPF.

  Recently, the same design issue has been discussed in
  MANET routing. It is in fact a wrong choice in OSPFv2
  regarding *identifying* unnumbered links. OSPFv3 uses
  the link local address to solve the problem. GMPLS
  Unnumbered also solved this problem using link local LSAs.

  One of the excellent extracts from Fred's mail:
  In a number of cases, it is possible to come up with
  more than one way to get to a specified neighbor and
  it is important for operational reasons which route
  you take. If you can't identify them easily, you can't
  do this. So it is not sufficient to say
  "I have two routes to this neighbor", you have to be
  able to identify them.

Venkata.

---

From: Acee Lindem <[email-masked]>
Date: Tue, 15 Apr 2003 14:50:09 -0400

>   "I have two routes to this neighbor", you have to be

What can't be done with parallel unnumbered link is the
back link check described in RFC 2328 section 16.1 (2)(b).
The base OSPF protocol doesn't provide a solution. I still
see it as an implementation choice as what to do. You can:

   1. Use them all the parallel unnumbered links.
   2. Only use one an unnumbered link if it is not a parallel
      link.
   3. Use a mechanism outside the base protocol (as discussed
      above).

Thanks,
Acee

--
Acee

---

From: Dennis Ferguson <[email-masked]>
Date: Tue, 15 Apr 2003 16:31:18 -0700

>    3. Use a mechanism outside the base protocol (as discussed

I may just be dumb but I don't get how putting addresses on the p2p links
fixes much of anything compared to not having them.  Even if you've
got addresses configured on the p2p links there is nothing in the base
protocol which requires both ends to agree on this configuration, or
which would guarantee that the addresses are unique, or which would
prevent circuits from being used (or even make it desirable to not use
the circuit) if there were a mismatch, so within the base protocol
you can't really depend on address configuration on p2p links even if it
is there.  It doesn't seem to change anything.  That is, the routers
attached to the links will need to depend on their adjacency databases
to determine which of the circuits are bidirectional, addresses or not,
while routers not attached to the links won't have any certain idea of
which of the links are actually in service, addresses or not.

What part of RFC 2328 makes section 16.1(2)(b) work better when you
have addresses on the p2p links?  It seems like trying to use addresses
to tell you anything more than you would know without the addresses is
a mechanism as far outside the protocol as, say, configuring or
exchanging the ifindices for unnumbered links would be.

Dennis Ferguson

---

From: Acee Lindem <[email-masked]>
Date: Wed, 16 Apr 2003 00:36:05 -0400

> exchanging the ifindices for unnumbered links would be.

Dennis,

Good point - the base protocol doesn't require the subnets for
neighbors on numbered P2P links to match so you really don't want
to try and match the interface address (link data) in a router LSA's
type 1 link with the corresponding LSA's type 1 link data or its type 3
links. There are implementations that require a subnet match for
neighbor adjacency on numbered P2P interfaces but this is contrary
to RFC 2328.

So the issues and implementation choices are similar for parallel
numbered and unnumbered P2P links. Currently, I've implemented a
fairly liberal bi-directional check (one back-link will suffice).
What is your take on this issue?

Thanks,
Acee

--
Acee

---

From: "Senthil K. Venkatachalam" <[email-masked]>
Date: Wed, 16 Apr 2003 12:17:04 -0400

>What is your take on this issue?

I think the bi-directional check mentioned above should be enough
for general SPF, which is the goal of RFC 2328.

It may not be sufficient for TE CSPF, where a path has be computed from
a remote node, and there has to be a way of identifying the unnumbered
interface
of a node several hops away.

Regards,
Senthil.