Subject: [trill] seeking help to understand a line from TRILL-ESADI draft

From: Swet kumar <[email-masked]>
Date: Tue, 17 Jul 2012 09:59:34 +0000

Hi Authors,

I am not able to understand the meaning of the following line in this draft: http://tools.ietf.org/pdf/draft-ietf-trill-esadi-00.pdf

"For robustness, if an ESADI instance has two or more ESADI neighbors
   and is not DRB and it receives no ESADI-CSNP PDUs for at least the
   CSNP Time (see Section 6.1) of the DRB, it MAY transmit an ESADI-
   CSNP."

This line is a part of section 4.1 (Sending of ESADI PDUs) on page number 12.
Please explain me what this line tries to convey.

Regards,
Swet

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 17 Jul 2012 15:27:16 -0400

Hi Swet,

On Tue, Jul 17, 2012 at 5:59 AM, Swet kumar <[email-masked]> wrote:
> Hi Authors,
>
>
> I am not able to understand the meaning of the following line in this draft:
> http://tools.ietf.org/pdf/draft-ietf-trill-esadi-00.pdf

Thanks for reviewing this document. It was just recently posted as a
WG document and I think it does need some more work.

> “For robustness, if an ESADI instance has two or more ESADI neighbors
>
>    CSNP.”

Do you really no understand what the sentence says? Or is it that you
don't understand what the reason is for this behavior?

The idea is that if the DRB on an ESADI virtual link is being flakey
or the virtual link is broken then, to maintain LSP synchronization,
it would be good for some other TRILL switch on that ESADI virtual
link to occasionally send a CSNP. The multi-hop ESADI pseudo-link is
inherently somewhat less reliable that a link between adjacent TRILL
switches. (You might think this could result in a flurry of CSNPs but
note that, due to the jitter in the IS-IS reliable flooding mechanism,
if there were several non-DRB TRILL switches on the link, as soon as
one sends a CSNP it will inhibit the others for a while.)

Anyway, although it doesn't make much difference. It should probably
say "one" instead of "two" in the text and it should not just be that
it has not received a CSNP but that it has not received or sent a
CSNP. So, I think the wording should be changes to:

   "For robustness, if an ESADI instance has one or more ESADI neighbors
   and is not DRB and it does not receive or send an ESADI-CSNP PDU
   for at least the CSNP Time (see Section 6.1) of the DRB, it MAY
   transmit an ESADI-CSNP."

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Wed, 18 Jul 2012 14:15:11 -0400

Seems to me that the MAY sentence all by itself is not helpful.

If sending occasionaly ESADI-CSNPs increases robustness, IMO, the spec
should say that and explain which scenarios its useful in. And then,
MAY doens't seem right either. SHOULD would seem to make more sense...

The RFC 2119 defintion of MAY says:

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

which doesn't seem to match the explanation for why the MAY sentence
is in the document.

Thomas

> > For robustness, if an ESADI instance has two or more ESADI neighbors
> >
> >    CSNP.

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

---

From: Radia Perlman <[email-masked]>
Date: Wed, 18 Jul 2012 12:12:52 -0700

Actually, perhaps ESADI shouldn't bother with CSNPs at all.  If each
RB participating in the ESADI instance included the sequence number of
its own LSP in its Hello for that ESADI instance, wouldn't that work?
We need to have each RB (in the ESADI instance) send Hellos
periodically anyway.

Radia

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 18 Jul 2012 15:23:36 -0400

Currently there are no Hellos in ESADI. Participation is determined
from the core IS-IS link state database.

Thanks,
Donald

---

From: Radia Perlman <[email-masked]>
Date: Wed, 18 Jul 2012 12:25:53 -0700

Oh right!  You just learn of your ESADI neighbors based on the core
instance LSPs.  Sorry about the confusion.

Radia

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 19 Jul 2012 02:25:33 -0400

Hi Thomas,

> MAY doens't seem right either. SHOULD would seem to make more sense...

I'm fine with SHOULD and including a sentence or two of justfication.
But it isn't actually occasionally at random, it is under specific
circumstances that indicate something is wrong and CSNPs are not being
received from the DRB.

Thanks,
Donald

---

From: Thomas Narten <[email-masked]>
Date: Thu, 19 Jul 2012 06:45:17 -0400

> circumstances that indicate something is wrong and CSNPs are not being

Then by all means please have the spec say that. The whole point of a
standard is to provide useful guidance to an implementor on whether
and when something should be implemented. Many (most?) implementors
will not be familiar with TRILL and its long WG history and will just
be going by what the spec says. 

Thomas

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 27 Jul 2012 11:25:48 -0400

Hi Thomas,

> be going by what the spec says.

OK, that can be included in the next revision.

Thanks,
Donald