Subject: [Isis-wg] draft-ietf-isis-3way-02.txt questions

From: Jeff Learman <[email-masked]>
Date: Wed, 24 May 2000 16:25:54 -0400

The procedures in draft-ietf-isis-3way-02 look great.  I have a suggestion:

It should be stated that this mechanism is unnecessary when using a
reliable link layer service, and that implementing this mechanism relaxes
certain requirements stated in ISO 10589 for the operation of IS-IS over
point-to-point links.  These requirements are:

 "a) Provision that both source and destination systems complete startup
     before PDU exchange can occur;
  b) Detection of remote start-up;
  c) Provision that no old PDUs be received after start-up is complete;
  d) Provision that no PDUs transmitted after a particular startup is
     complete are delivered out of sequence;
  e) Provision that failure to deliver a specific subnetwork SDU will
     result in the timely disconnexion of the subnetwork connection in
     both directions and that this failure will be reported to both systems;
     and
  f) Reporting of other subnetwork failures and degrade subnetwork conditions.
  g) The following events are "very low probability", ..."

Clearly, the draft relieves the subnetwork of requirements a, b, e, and f.
I don't know whether the mechanism has any impact on requirements c and d.

Regards,
Jeff

____________________________________________________________________

  Jeff Learman                           Internet:     [email-masked]
  Engineering Manager                    Voice:     (734)-975-7323
  ONE (Open Networks Engineering, Inc)   Fax:       (734)-975-6940
  2725 South Industrial Pkwy, Suite 100
  Ann Arbor, MI  48104  USA
____________________________________________________________________

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: "Rajesh Saluja" <[email-masked]>
Date: Thu, 25 May 2000 09:36:27 -0400

Jeff,
It is a valid point. Thanks for your suggestion.

Regards,
Rajesh

--

-------------------------------------------------------------
Rajesh Saluja
Nortel Networks Inc 600 Technology Park Billerica, MA  01821
Ph: (978) 288-7791      Fax: (978) 670-8760
--------------------------------------------------------------

---

From: Jeff Learman <[email-masked]>
Date: Tue, 30 May 2000 14:16:43 -0400

Rajesh,

Does the 3-way handshake resolve the problem of a loss of the
initial CSNP?  I see how the probability is reduced by handling
the restart case.  But over Frame Relay, for example, the first
CSNP could be dropped without a restart.  Is this covered by the
procedure?  If not, a timer could be added forcing a circuit
restart if the CSNP is not received within a reasonable time.

Also, if the first CSNP is lost, I would expect it to take up to
20 minutes for all systems to regenerate their LSPs, causing them
to be flooded throughout the area and correcting the problem
(not 18 hours).  How did you come up with 18 hours?

Thanks,
Jeff

---

From: Henk Smit <[email-masked]>
Date: Tue, 30 May 2000 20:36:06 +0200 (MEST)

> Also, if the first CSNP is lost, I would expect it to take up to

  It should be noted that in addition to sending a CSNP, you must also
 set the SRM bit for this interface on all LSPs. If the CSNP from your
 neighbor does arrive, you can probably unset the SRM bits for lots of LSPs.
 If the CSNP from your neighbor is dropped, you end up sending all LSPs
 to your neighbor. That is gonna take more resources than strictly needed,
 but at least you are sure that the LSPDBs are synced quickly.

> (not 18 hours).  How did you come up with 18 hours?

  The Remaininglifetime in the LSPs is 2 bytes. So in theory you could
 set the Remaininglifetime of a new LSP to 65535 seconds. If you
 adhere strictly to 10589, such an LSP should be considered to be
 corrupted.

  However, IMHO there is no need to be so restrictive. Some implementations
 will work fine with Remaininglifetimes larger than 20 minutes. Some
 implementations will even allow you to configure the router to set the
 Remaininglifetime higher than 20 minutes on new LSPs. This helps to bring
 down the "background flooding noise".

  65535 seconds is 18.7 hours. Voila ....

        Henk.