Re: [babel] Comments about rfc7298bis

Denis Ovsienko <denis@ovsienko.info> Wed, 02 May 2018 22:31 UTC

Return-Path: <denis@ovsienko.info>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65C312DA4B for <babel@ietfa.amsl.com>; Wed, 2 May 2018 15:31:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a62Jbe9wsI6f for <babel@ietfa.amsl.com>; Wed, 2 May 2018 15:31:20 -0700 (PDT)
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D9412DA49 for <babel@ietf.org>; Wed, 2 May 2018 15:31:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1525300276; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=1242; bh=pJnUnZpwbEKmzT/UHBo0WljUaSdPjGBnuipMvbhKESQ=; b=OPdIW0G1Zo6QJODmvxO7MCfVId2ICyUCyWjXiMp48EhkRFttqO6Gn8/vOx1RGSHQ hMSVlYMhLa/HaXhdbuIvecVxJNNi5Fbz8yvJYF4qjnhEL9TWVObMCyCF9gNNNr05dUh Ml4z+fqDYemCCCCoWFx5XL0wZdrcHkdQt49lh0+g=
Received: from mail.zoho.com by mx.zohomail.com with SMTP id 15253002765451013.4680357088488; Wed, 2 May 2018 15:31:16 -0700 (PDT)
Date: Wed, 02 May 2018 23:31:16 +0100
From: Denis Ovsienko <denis@ovsienko.info>
To: Babel at IETF <babel@ietf.org>
Message-ID: <16322fb2d40.b754c16418709.3274574589997739202@ovsienko.info>
In-Reply-To: <87sh7aaqpw.wl-jch@irif.fr>
References: <87fu4huzgj.wl-jch@irif.fr> <1628e298460.cd82970b35329.4945272877112645380@ovsienko.info> <87muyi3eqi.wl-jch@irif.fr> <16296069fec.e13616a29759.8282754479379679955@ovsienko.info> <878ta1y8k0.wl-jch@irif.fr> <87sh7aaqpw.wl-jch@irif.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/30kSdcu50beyuIHX4P4K8Fi7yCg>
Subject: Re: [babel] Comments about rfc7298bis
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 May 2018 22:31:22 -0000

---- On Wed, 02 May 2018 18:54:03 +0100 Juliusz Chroboczek  wrote ---- 
>>>> What happens if the number of neighbours is so large that the complete set 
>>>> of TC/PC echos does not fit in a full-size packet? 
> 
>>> The same thing happens as if there is no authentication at all and the 
>>> number of neighbours is so large that the complete set of IHU TLVs does 
>>> not fit. 
> 
>> I'm not sure I understand. The set of IHUs can be easily split across 
>> multiple packets -- the absence of an IHU does not imply that the 
>> neighbour has been dropped. If I understand correctly (correct me if I'm 
>> wrong), your draft requires sneding the full set of IHU+TC/PC echo in 
>> a single packet. If I'm right, then a mechanism is needed to deal with 
>> overflow, no? 
> 
>Denis, 
> 
>Did I miss an e-mail? I don't see an answer to the above. 

1. Terminology: the data unit is called a TS/PC number, this has been the term since 2012.
2. Protocol encoding: the "echo" TS/PC sub-TLV is specific to an IHU TLV, the additional requirement for IHU TLVs grouping or placement you describe does not exist.

If you go back a couple messages up this thread, hopefully you will see we had discussed both points before.

-- 

    Denis Ovsienko