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

[Thomas Narten <[e-mail]>]

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

Donald Eastlake <[e-mail]> writes:


> Hi Swet,

> On Tue, Jul 17, 2012 at 5:59 AM, Swet kumar <[e-mail]> 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
> >
> >    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.”

> 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   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]

> > 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
> _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill