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

Donald Eastlake <d3e3e3@gmail.com> Thu, 19 July 2012 06:25 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF1721F865C for <trill@ietfa.amsl.com>; Wed, 18 Jul 2012 23:25:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.518
X-Spam-Level:
X-Spam-Status: No, score=-103.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRsn7K9ULKn4 for <trill@ietfa.amsl.com>; Wed, 18 Jul 2012 23:25:02 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 60ADD21F865A for <trill@ietf.org>; Wed, 18 Jul 2012 23:25:02 -0700 (PDT)
Received: by obbwc20 with SMTP id wc20so3775813obb.31 for <trill@ietf.org>; Wed, 18 Jul 2012 23:25:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=CIX/WxvkD7tZjt/p3MXBOSYcPYHk5JXVG3QoTBjZBt8=; b=bfcVXcHRnvVtpCAJID/CUtlsZd5pKY1T6zso5ziyWYHWFQLWMcFBFf1tWQod2MTMHI qp98mbLgkwYKfd02bo4+gZnMyNyQYGO7cWzi/Vh8VG1pNGvDiOYbEIFqDiwAbWj6tm7I psQA1/MsseTvjyUhBlYlShlcCLBNRtpb7VmyosYXg3crNVJjwwMSHWihkd3NWDeVzujp AgLnyySKkL3MkP04kRk0IaSWC6E9xbKSBtkHpnz0SsbxABApUuQgAJEr8hwPAYlyoteC zooMoF+bPZDWGy/DlCawmpeIj3fxz7v7uHJtvL/VrDxddjCyohbs0cS2VP7Pv3KyN4bN Atdg==
Received: by 10.50.196.201 with SMTP id io9mr326282igc.58.1342679153829; Wed, 18 Jul 2012 23:25:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.16.227 with HTTP; Wed, 18 Jul 2012 23:25:33 -0700 (PDT)
In-Reply-To: <201207181815.q6IIFB76016094@cichlid.raleigh.ibm.com>
References: <06379F8DF406F04189CAE40F1A8FB12501D602BE@BL2PRD0510MB351.namprd05.prod.outlook.com> <CAF4+nEHPAfXjJxohOry0JdafjFDi=KemLJQh+ZYzuzi03cjwLw@mail.gmail.com> <201207181815.q6IIFB76016094@cichlid.raleigh.ibm.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 19 Jul 2012 02:25:33 -0400
Message-ID: <CAF4+nEHrzOFCdgAFZkC31+6rOGvG1RmYqb_cpyUV6=aaTF3j6A@mail.gmail.com>
To: Thomas Narten <narten@us.ibm.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: Swet kumar <swet.kumar@ipinfusion.com>, "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] seeking help to understand a line from TRILL-ESADI draft
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jul 2012 06:25:03 -0000

Hi Thomas,

On Wed, Jul 18, 2012 at 2:15 PM, Thomas Narten <narten@us.ibm.com> wrote:
> 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...

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.

> 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.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

> Thomas
>
> Donald Eastlake <d3e3e3@gmail.com> writes:
>
>
>> Hi Swet,
>
>> On Tue, Jul 17, 2012 at 5:59 AM, Swet kumar <swet.kumar@ipinfusion.com> 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   +1-508-333-2270 (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>>  d3e3e3@gmail.com
>
>> > 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
>> trill@ietf.org
>> https://www.ietf.org/mailman/listinfo/trill
>
>
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
>