Subject: [Rift] OSPF/RIFT Neighbor & Adjacency

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 1 May 2018 19:53:24 +0000

Pulling this out to its own from the other thread.

--------------------------------------------

   A node tries to form a three way adjacency if and only if
   (definitions of LEAF_ONLY are found in Section 4.2.9) ...

zzh> The draft does not distinguish between neighbors and adjacency. I think it's better to do so as in OSPF case:
        Neighboring routers
            Two routers that have interfaces to a common network.
            Neighbor relationships are maintained by, and usually
            dynamically discovered by, OSPF's Hello Protocol.

        Adjacency
            A relationship formed between selected neighboring routers
            for the purpose of exchanging routing information.  Not
            every pair of neighboring routers become adjacent.

Prz> yes, conciously. we really just have a p2p adjacency/neighbor which is the same for RIFT. OSPF "adjacency" concept is quite difficult to implement and really just an optimization for large number of parallel links.  Nothing prevents a RIFT implementation to be "smart" in flooding about parallel links but each link is really a separate adjacency.
--------------------------------------------
In OSPF, even with parallel links between two neighbors, there will be separate adjacencies - one adjacency on each link and no different from RIFT here.
However, my point here is that the three-way handshake should be separate from adjacency forming and it does not care about level/pod/whatever. The handshake only confirms two-way communication; then based on the exchanged level/pod information a decision is made whether to bring up adjacency. When a neighbor advertises a different level, adjacency may form or be torn down, but there is no need to restart handshake.
Jeffrey

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 1 May 2018 17:48:22 -0700

On Tue, May 1, 2018 at 12:53 PM, Jeffrey (Zhaohui) Zhang <[email-masked]
> wrote:

> zzh> The draft does not distinguish between neighbors and adjacency. I
> think it's better to do so as in OSPF case:
>         Neighboring routers
> Prz> yes, conciously. we really just have a p2p adjacency/neighbor which
> is the same for RIFT. OSPF "adjacency" concept is quite difficult to
> implement and really just an optimization for large number of parallel
> links.  Nothing prevents a RIFT implementation to be "smart" in flooding
> about parallel links but each link is really a separate adjacency.
> In OSPF, even with parallel links between two neighbors, there will be
> separate adjacencies - one adjacency on each link and no different from
> RIFT here.
>
yes, but OSPF has one neighbor, RIFT doesn't have "neighbors" or rather
adjacency=neighbor

> However, my point here is that the three-way handshake should be separate
> from adjacency forming and it does not care about level/pod/whatever. The
> handshake only confirms two-way communication; then based on the exchanged
> level/pod information a decision is made whether to bring up adjacency.
> When a neighbor advertises a different level, adjacency may form or be torn
> down, but there is no need to restart handshake.
>
there is a gotcha-22. Unless you've chosen your level via ZTP you can't
form adjacency (because level matching is part of adjacency forming) so ZTP
must be part of adjacency forming, i.e. adjacency forming choses level &
when level match the adjacency 3-ways. I'll show flows tommorow ...  In a
sense what you suggest happens, one-way is basically ZTP (or think of it as
two-way, doesn't matter) and once ZTP provides levels that are workable,
3-way forms ...

--- tony