Re: [manet-dlep-rg] DLEP Capabilities exchange

Teco Boot <teco@inf-net.nl> Tue, 21 January 2014 21:47 UTC

Return-Path: <teco@inf-net.nl>
X-Original-To: manet-dlep-rg@ietfa.amsl.com
Delivered-To: manet-dlep-rg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0491A0229 for <manet-dlep-rg@ietfa.amsl.com>; Tue, 21 Jan 2014 13:47:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 0NXZbpYljn7Q for <manet-dlep-rg@ietfa.amsl.com>; Tue, 21 Jan 2014 13:47:38 -0800 (PST)
Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id A497A1A01D3 for <manet-dlep-rg@ietf.org>; Tue, 21 Jan 2014 13:47:37 -0800 (PST)
Received: by mail-ee0-f49.google.com with SMTP id d17so4415948eek.36 for <manet-dlep-rg@ietf.org>; Tue, 21 Jan 2014 13:47:36 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=O7NiCHLnFLxtyrC56opDQ0ANHwlefKGs6lbJmDgJ02Y=; b=aba6Y5SJKIxGZA9QeBOR8fTbMXeFsRXBPGcKEvHXARl6FnrjRnTfFTpgMUzCWmyEuc qhXL01BIBtaKuPTzqof7GF0jjMN2BdSQME2vxIIdKupdJjgkXvlamOkQWE61yumcNULd ICD83E7Ixp14XeH28nUaGpNqrAtriq6jWZgV4kwY9mCX73LgxhvA4eLkKVknMsfM7eyN B1LamXIJN/Fram+da7qn0PvHGQvGcndjNFUOn8Xkd1tzUQC6GDdis1YDUvCKt7J75z/a rL0j97GJDfnepl5xZCa+wrREgoLgd6+rUdU52y59cGtVW0fa4ef9I/j2H3kGjjdgtOBK giAQ==
X-Gm-Message-State: ALoCoQmarigFjCF9DIqE6hyKbJwt2IQbcmshGYpjJnK53tPKzjzQOCsiQAJZ69GNs363Uw8J4KiE
X-Received: by 10.14.251.68 with SMTP id a44mr13242158ees.64.1390340856427; Tue, 21 Jan 2014 13:47:36 -0800 (PST)
Received: from [10.175.173.27] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id u7sm19271278eep.11.2014.01.21.13.47.34 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Jan 2014 13:47:35 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Teco Boot <teco@inf-net.nl>
In-Reply-To: <3BC2E4AC-CD56-4AEA-AB12-4197ABC3611F@cisco.com>
Date: Tue, 21 Jan 2014 22:47:33 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9B289123-CB0A-4FEA-8F84-08EEE2A6D45C@inf-net.nl>
References: <3BC2E4AC-CD56-4AEA-AB12-4197ABC3611F@cisco.com>
To: Stan Ratliff <sratliff@cisco.com>
X-Mailer: Apple Mail (2.1827)
Cc: "\(manet-dlep-rg@ietf.org\) manet-dlep-rg@ietf.org Group" <manet-dlep-rg@ietf.org>
Subject: Re: [manet-dlep-rg] DLEP Capabilities exchange
X-BeenThere: manet-dlep-rg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DLEP Radio Group <manet-dlep-rg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet-dlep-rg>, <mailto:manet-dlep-rg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet-dlep-rg/>
List-Post: <mailto:manet-dlep-rg@ietf.org>
List-Help: <mailto:manet-dlep-rg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet-dlep-rg>, <mailto:manet-dlep-rg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2014 21:47:40 -0000

Poeh, way back struggling with this.

Yes, this kind of information exchange is useful. But why would this example need negotiation? Just sending the TLV is OK, and routers can drop it or use it at own willing.

For for example a BW allocation sub protocol, I can imagine both modem and router MUST first agree before bothering each other with a "foreign DLEP sub-protocol language". The negotiation SHOULD NOT terminate the DLEP session. And can take place at any time after DLEP session setup.

The flow control and link characteristics request capabilities could be negotiated.

Teco


Op 21 jan. 2014, om 21:18 heeft Stan Ratliff (sratliff) <sratliff@cisco.com> het volgende geschreven:

> Gentlemen, 
> 
> 
> Well, sigh…  I've been frankly trying to avoid this, but it's a subject I want to breach - if not for DLEP-05, then maybe for an 06. 
> 
> I've been thinking again about some exchange of capabilities. Not for a DLEP session startup, but to cover some specific use cases. The first one I'll throw out is this: 
> 
> Consider a deployment using OSPF, over satellite. That OSPF network is defined as a standard broadcast (Ethernet) segment, with a Designated Router (DR) and a Backup DR (BDR). In the satellite implementation I'm considering, it would be a good thing if the DR was co-located with the SatCom "Network Controller". 
> 
> So, I'm thinking about a capabilities exchange, where the modem (the satcom terminal) tells the router "I'm the NC". This would, in turn, cause the connected router to be "very willing" (whatever that means) to be the DR in an OSPF election (the next election that occurs on this link)… There would also have to be an "I'm NOT the NC anymore" message that flows from modem to router if/when that function is reassigned in the network. 
> 
> I'm sure there are other cases. Let's see if we can make a run at enumerating (and hopefully "generalizing") them.
> 
> Regards,
> Stan
> _______________________________________________
> manet-dlep-rg mailing list
> manet-dlep-rg@ietf.org
> https://www.ietf.org/mailman/listinfo/manet-dlep-rg