Subject: [Rift] Question on database exchange process

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 30 Apr 2018 12:55:37 +0000

Tony,

4.2.3.5.  Initial and Periodic Database Synchronization

   The initial exchange of RIFT is modeled after ISIS with TIDE being
   equivalent to CSNP and TIRE playing the role of PSNP.

I suppose more details will be filled in (and this is one of the pieces for which contribution work from WG members are welcome).

I am not very familiar with ISIS protocol details. I came from OSPF background and ISO specs are not easily accessible - I assume there are many others like me. On the other hand, people who are very familiar with ISIS details can easily dig into OSPF details.

With that, I am wondering if in general we could refer to OSPF instead of ISIS when there is not fundamental difference between the two - this will greatly help getting more people involved. Of course, if there are differences and a design choice is made to go with ISIS style, then reference to ISIS is in order.

In particular on this initial database exchange topic, the OSPF way uses a master/slave model:

       This sending and receiving of Database Description packets is
        called the "Database Exchange Process".  During this process,
        the two routers form a master/slave relationship.  Each Database
        Description Packet has a sequence number.  Database Description
        Packets sent by the master (polls) are acknowledged by the slave
        through echoing of the sequence number.  Both polls and their
        responses contain summaries of link state data.  The master is
        the only one allowed to retransmit Database Description Packets.
        It does so only at fixed intervals, the length of which is the
        configured per-interface constant RxmtInterval.

Does ISIS use the same?

Jeffrey

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 30 Apr 2018 08:58:03 -0700

OK, so ISO spec of ISIS is accessible for an obolus via e.g.
https://www.iso.org/standard/30932.html

It is probably not the easiest consumable spec so I suggest Hannes'
well-written, albeit by now in some respects dated book
https://www.springer.com/us/book/9781852338220  . AFAIR it was describing
the CSNP/PSNP mechanism quite well.

On the other hand, it may benefit to write the processing for TIRE/TIDE
stuff cleanly independentlyof the very old ISO doc so we have a public
domain doc as you say.

RIFT chose to do the database sync the ISIS way very conciously (and no, it
is quite different from OSPF, especially in the initial phase) since I
suffered somewhat prolonged exposure to both protocols ;-) & operationally
I think ISIS comes out on top here for many reasons, the OSPF initial sync
brings a somewhat complex behavior with it (well understood by now of
course) and in case of implementation problems a certain fragility since no
periodic database sanity check is exchanged between nodes. Generally, ISIS
synchronization is strongly self-stabilizing and works for many, even
fairly "loose" implementations. Flooding can start before initial CSNPs
completed, after and the only thing really is that PSNPs are both sent
reliably to request missing pieces (and even this and the ack'ing is
self-stabilizing when CSNPs reflect reception or presence of newer
versions).

Yes, we have people working on the LIE FSM now and I am perfectly happy to
suppo rt any volunteers who are willing to step up and start to formalize
an appendix with the flooding FSM/procedure. The FSM is fairly simple
albeit the set of procedures is a bit of a write-down.

Then, you can of course just play with the implementation and observe how
TIRE/TIDEs are generated to get a jest of it that way ;-)

thanks

--- tony

On Mon, Apr 30, 2018 at 5:55 AM, Jeffrey (Zhaohui) Zhang <[email-masked]
> wrote:

> I suppose more details will be filled in (and this is one of the pieces
> for which contribution work from WG members are welcome).
>
> I am not very familiar with ISIS protocol details. I came from OSPF
> background and ISO specs are not easily accessible - I assume there are
> many others like me. On the other hand, people who are very familiar with
> ISIS details can easily dig into OSPF details.
>
> With that, I am wondering if in general we could refer to OSPF instead of
> ISIS when there is not fundamental difference between the two - this will
> greatly help getting more people involved. Of course, if there are
> differences and a design choice is made to go with ISIS style, then
> reference to ISIS is in order.
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 30 Apr 2018 21:10:48 +0000

ISO 10589:2002 is available for free here:  http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

FWIW…Having the ability to send periodic database summaries (AKA CSNP) is very handy – IS-IS wins on that count.

However, completing database exchange BEFORE advertising an adjacency avoids a number of startup issues – so OSPF wins on that count.

I haven’t dug deeply enough into RIFT to know exactly where you are with these things, but if you want the best of both IGPs …

   Les

From: Rift <[email-masked]> On Behalf Of Tony Przygienda
Sent: Monday, April 30, 2018 8:58 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rift] Question on database exchange process

OK, so ISO spec of ISIS is accessible for an obolus via e.g. https://www.iso.org/standard/30932.html
It is probably not the easiest consumable spec so I suggest Hannes' well-written, albeit by now in some respects dated book https://www.springer.com/us/book/9781852338220  . AFAIR it was describing the CSNP/PSNP mechanism quite well.

On the other hand, it may benefit to write the processing for TIRE/TIDE stuff cleanly independentlyof the very old ISO doc so we have a public domain doc as you say.
RIFT chose to do the database sync the ISIS way very conciously (and no, it is quite different from OSPF, especially in the initial phase) since I suffered somewhat prolonged exposure to both protocols ;-) & operationally I think ISIS comes out on top here for many reasons, the OSPF initial sync brings a somewhat complex behavior with it (well understood by now of course) and in case of implementation problems a certain fragility since no periodic database sanity check is exchanged between nodes. Generally, ISIS synchronization is strongly self-stabilizing and works for many, even fairly "loose" implementations. Flooding can start before initial CSNPs completed, after and the only thing really is that PSNPs are both sent reliably to request missing pieces (and even this and the ack'ing is self-stabilizing when CSNPs reflect reception or presence of newer versions).
Yes, we have people working on the LIE FSM now and I am perfectly happy to suppo rt any volunteers who are willing to step up and start to formalize an appendix with the flooding FSM/procedure. The FSM is fairly simple albeit the set of procedures is a bit of a write-down.
Then, you can of course just play with the implementation and observe how TIRE/TIDEs are generated to get a jest of it that way ;-)

thanks
--- tony

On Mon, Apr 30, 2018 at 5:55 AM, Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Tony,

Does ISIS use the same?

Jeffrey

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 30 Apr 2018 21:35:35 +0000

Hi Les,

From: Les Ginsberg (ginsberg) <[email-masked]>
Sent: Monday, April 30, 2018 5:11 PM
To: Tony Przygienda <[email-masked]>; Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]
Subject: RE: [Rift] Question on database exchange process

ISO 10589:2002 is available for free here:  http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__standards.iso.org_ittf_PubliclyAvailableStandards_index.html&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=PXjbTS4lJO9LL8ngiDQYlI2e7-RvhVDceZ1pevfPBso&s=x9IQUrhC-9me4dW43rOspkZI5WFxmqThg3VvoTGZO3s&e=>

Zzh> Great.

Zzh> Seems that CSNP is only for LAN and not used for P2P interfaces?

Zzh>    b) Otherwise (C is a point-to-point circuit, including non-DA DED circuits and virtual links), do nothing. CSNPs are only
transmitted on point-to-point circuits at initialisation.

Zzh> Hmm … I see different views on that already J

Zzh> Veterans like you/Tony/others are definitely needed to make sure that we on the right track. The specific context for my comment about “refer to OSPF if possible” is to lower the barrier for new blood to be actively involved J

Thanks!
Jeffrey

   Les

From: Rift <[email-masked]<mailto:[email-masked]>> On Behalf Of Tony Przygienda
Sent: Monday, April 30, 2018 8:58 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Rift] Question on database exchange process

OK, so ISO spec of ISIS is accessible for an obolus via e.g. https://www.iso.org/standard/30932.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iso.org_standard_30932.html&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=PXjbTS4lJO9LL8ngiDQYlI2e7-RvhVDceZ1pevfPBso&s=W__cYYktoTh9NkJHW-Ie02mtBxQ3Ywwzw2cK1SOUorg&e=>
It is probably not the easiest consumable spec so I suggest Hannes' well-written, albeit by now in some respects dated book https://www.springer.com/us/book/9781852338220<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.springer.com_us_book_9781852338220&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=PXjbTS4lJO9LL8ngiDQYlI2e7-RvhVDceZ1pevfPBso&s=Bbizu_TraQJUx0KpUBGYVl6PDqK4PVhQu9ic6EV9img&e=>  . AFAIR it was describing the CSNP/PSNP mechanism quite well.

thanks
--- tony

Does ISIS use the same?

Jeffrey

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 30 Apr 2018 22:01:58 +0000

Jeffrey -

From: Jeffrey (Zhaohui) Zhang <[email-masked]>
Sent: Monday, April 30, 2018 2:36 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; Tony Przygienda <[email-masked]>
Cc: [email-masked]
Subject: RE: [Rift] Question on database exchange process

Hi Les,

From: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Sent: Monday, April 30, 2018 5:11 PM
To: Tony Przygienda <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Rift] Question on database exchange process

Zzh> Great.

[Les:] It is true that the base spec (10589) only defines sending CSNPs on P2P links at adjacency bringup – but ISO 10589 was written when it was assumed that all link layer protocols on P2P links were reliable.
That assumption obviously no longer holds – particularly since we do P2P on Ethernet routinely now.

Also, flooding optimizations such as mesh groups (and more sophisticated solutions soon to come) depend on periodic CSNPs to make them more robust.
So periodic CSNPs are definitely available from multiple implementations on P2P links.

Zzh> Hmm … I see different views on that already ☺

[Les:] Yes – I wouldn’t even attempt to convince Tony to change his position. ☺
But having defined IS-IS extensions to deal with issues arising from the lack of adjacency bringup synchronization (see SA bit discussion in RFC 5306) I’ll stand by my position.

   Les

Zzh> Veterans like you/Tony/others are definitely needed to make sure that we on the right track. The specific context for my comment about “refer to OSPF if possible” is to lower the barrier for new blood to be actively involved ☺

Thanks!
Jeffrey

   Les

thanks
--- tony

Does ISIS use the same?

Jeffrey

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 30 Apr 2018 15:27:16 -0700

On Mon, Apr 30, 2018 at 2:10 PM, Les Ginsberg (ginsberg) <[email-masked]

> PubliclyAvailableStandards/index.html

OK, I seemed to remember we had some kind of IETF effort ages ago to make
it freely available but forgot all details ... thanks Les.

> However, completing database exchange BEFORE advertising an adjacency
> avoids a number of startup issues – so OSPF wins on that count.
>

well, nothing prevents you from implementing ISIS that way really AFAIR ;-)
And overload timeout is really working quite well AFAIR ...

>
>
> I haven’t dug deeply enough into RIFT to know exactly where you are with
> these things, but if you want the best of both IGPs …
>

CSNP/PSNP pretty much conceptually taken without modifications (TIRE/TIDE
are 1:1 the same things) since  I don't see how it can be done much better
after all those years playing with it ;-)

What is unnecessary these days (especially in DC) is the excessive shaping
OSPF/ISIS are doing due to the general nature of topologies/links they have
to support.
With modern link speeds & processors in data centers amazing flooding
throughput is possible IME and RIFT caters to that (especially if one uses
the optimal flooding reduction on top we just put out in -01 ;-).
In fact I did not put anything into the spec (yet) waiting for more
implementations and opinions albeit I do have ideas I tried & found working
;-) ...

--- tony