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

Radia Perlman <radiaperlman@gmail.com> Wed, 18 July 2012 19:12 UTC

Return-Path: <radiaperlman@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 918BA11E818C for <trill@ietfa.amsl.com>; Wed, 18 Jul 2012 12:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.562
X-Spam-Level:
X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 dpoQEwv5mj7M for <trill@ietfa.amsl.com>; Wed, 18 Jul 2012 12:12:03 -0700 (PDT)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 770CC11E8189 for <trill@ietf.org>; Wed, 18 Jul 2012 12:12:03 -0700 (PDT)
Received: by vcbfo14 with SMTP id fo14so1505865vcb.31 for <trill@ietf.org>; Wed, 18 Jul 2012 12:12:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2Dj7YgPdh6PhB0caohZSteFe2nwsYL/Y+yq1IxZphy0=; b=MegvHinns1jlq1RYLeXj2/78cLRf0v1ow1AVqKPJawbkTuH4uJrmfqhXU0DQCfhmyu M2eFxSACyYH6AcECgUbswjp+dAFSjFundXyVgGOilOhlJaLAVpO2VpZQh16GNORj7FZi N9kFRKyDB1xcl6jS8bWcKNd51yX30slMmNeDNKQ61kgz4sXhMrRVMLy3YQlNAlQfTkAZ 9AFe/MP1YRFnCrzyQ+lvf0j+jQ/8vSjtZx1jpelbJLLrzMpcUApEHmGCJW1OBJ9ogng7 SS7EMcpxMXIsCJAdGAA58D2BzyjbpDCLv80A1niSTr6RIJqFx7uqtqjekf//bRI17z8W dvAg==
MIME-Version: 1.0
Received: by 10.52.27.72 with SMTP id r8mr1338201vdg.14.1342638772564; Wed, 18 Jul 2012 12:12:52 -0700 (PDT)
Received: by 10.58.217.136 with HTTP; Wed, 18 Jul 2012 12:12:52 -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>
Date: Wed, 18 Jul 2012 12:12:52 -0700
Message-ID: <CAFOuuo5MAESfFz-5FzKRVOtVUFrvc4rTJdOBCxzStsn+Y4kOpw@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: Thomas Narten <narten@us.ibm.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: Donald Eastlake <d3e3e3@gmail.com>, 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: Wed, 18 Jul 2012 19:12:04 -0000

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

On Wed, Jul 18, 2012 at 11:15 AM, 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...
>
> 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 <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
>