From nobody Sat Sep 2 02:21:14 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75BC132335 for ; Sat, 2 Sep 2017 02:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 VzdZOD0qyDLk for ; Sat, 2 Sep 2017 02:21:10 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3552712426E for ; Sat, 2 Sep 2017 02:21:10 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Sat, 2 Sep 2017 10:20:45 +0100 From: Rick Taylor To: Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] New DLEP extension drafts Thread-Index: AQHTIjqdj1aPXRKHkUWtp7lq2oY7e6Kffs2AgAHOTrA= Date: Sat, 2 Sep 2017 09:20:43 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801D30BA2E9@tss-server1.home.tropicalstormsoftware.com> References: <1500890455.2721.234.camel@tropicalstormsoftware.com> <1504171326.31980.2.camel@tropicalstormsoftware.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] New DLEP extension drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2017 09:21:13 -0000 VGhhbmtzIGZvciB0aGUgY29tbWVudHMsIEhlbm5pbmcsIHJlcGxpZXMgaW5saW5lLi4uDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGVubmluZyBSb2dnZQ0KPiBTZW50OiAwMSBT ZXB0ZW1iZXIgMjAxNyAwNzoxOA0KPiBUbzogbWFuZXRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IFttYW5ldF0gTmV3IERMRVAgZXh0ZW5zaW9uIGRyYWZ0cw0KPiANCj4gQW0gMzEuMDguMjAxNyB1 bSAxMToyMiBzY2hyaWViIFJpY2sgVGF5bG9yOg0KPiA+IEhpIEFsbCwNCj4gDQo+IE9rYXksIHRp bWUgdG8gZ2V0IHRoZSBiYWxsIHJvbGxpbmcgZm9yIHNlcnZpY2UgZGlzY292ZXJ5Lg0KDQpFeGNl bGxlbnQhICBUaGlzIGRyYWZ0IHdhcyBmaXJzdCBzdGFydGVkIDIgeWVhcnMgYWdvLCBzbyBiaXRz IG9mIGl0IGFyZSBkZWZpbml0ZWx5IHVuY2xlYXIvb3V0LW9mLWRhdGUuDQoNCj4gDQo+IEkgbXVz dCBhZG1pdCBJIGFtIG5vdCB0aGF0IGhhcHB5IHdpdGggdGhlIGRyYWZ0IGluIGl0cyBjdXJyZW50 IGZvcm0uDQo+IA0KPiBGaXJzdCByZWFzb24gaXMgdGhlIHRoYXQgdGhlIGRyYWZ0IGZvY3VzZXMg b24gYW5ub3VuY2luZyByb3V0ZXIgc2VydmljZXMgdG8NCj4gb3RoZXIgcm91dGVycy4gVGhpcyBt YWtlcyBpdCBwcmFjdGljYWxseSBuZWNlc3NhcnkgdG8gYWRkIGFuIG92ZXIgdGhlIGFpcg0KPiBj b21wb25lbnQgdG8gRExFUC4gSSB0aG91Z2h0IHdlIGFncmVlZCB0aGF0IG9uZSBvZiB0aGUgZGVz aWduIGdvYWxzIG9mDQo+IERMRVAgd2FzIG9ubHkgdG8gY29tbXVuaWNhdGUgYmV0d2VlbiB0aGUg bG9jYWwgcmFkaW8gYW5kIHRoZSBsb2NhbCByb3V0ZXIsDQo+IGV4Y2hhbmdpbmcgYWxyZWFkeSBl eGlzdGluZyBsb2NhbCBrbm93bGVkZ2UuDQoNCk9rYXkuLi4gSSdsbCBhbnN3ZXIgdGhpcyBwb2lu dCBpbiBwYXJ0czoNCmEpIEkgcmVtZW1iZXIgdGhlIGVhcmx5IERMRVAgZGlzY3Vzc2lvbnMgYWdy ZWVkIHRoYXQgdGhlIERMRVAgcHJvdG9jb2wgd291bGQgbm90IGRlZmluZSBob3cgb3Igd2hhdCB3 YXMgc2VudCBvdmVyIHRoZSBhaXIsIGJ1dCBkaWQgcmVxdWlyZSB0aGF0IHNvbWV0aGluZyB3YXMg c2VudCBpbiBvcmRlciB0byBmdW5jdGlvbi4gIFRoZSBhc3N1bXB0aW9uIGJlaW5nIHRoYXQgbmVh cmx5IGFsbCByYWRpbyBzeXN0ZW1zIGhhdmUgc29tZSBraW5kIG9mIGNvbnRyb2wgcGxhbmUuICBE TEVQIG9ubHkgZGVmaW5lcyB0aGUgJ2hvdyBhbmQgd2hhdCBmb3JtYXQnIG9mIHRoZSBsb2NhbCBj b21tdW5pY2F0aW9uLiAgDQoNCmIpIFllcywgdGhpcyBleHRlbnNpb24gZG9lcyByZXF1aXJlIHNv bWUgZGF0YSB0byBiZSB0cmFuc21pdHRlZCBvdmVyIHRoZSBhaXIgKGl0IGRvZXMgbm90IHNwZWNp ZnkgaG93IG9yIGluIHdoYXQgZm9ybWF0LCBqdXN0IGxpa2UgRExFUCksIGJ1dCBhcyBhbiBleHRl bnNpb24sIGl0IGlzIG9wdGlvbmFsLg0KDQo+IA0KPiBJIHRoaW5rIERMRVAgaXMgdGhlIHdyb25n IHByb3RvY29sIHRvIGV4Y2hhbmdlIGtub3dsZWRnZSBiZXR3ZWVuIHJvdXRlcnMNCj4gYW5kIEkg YW0gc3VyZSB0aGUgSUVURiBhbHJlYWR5IGhhcyBwcm90b2NvbHMgZm9yIHRoZSB0d28gcm91dGVy cyBleGNoYW5naW5nDQo+IHNlcnZpY2UgaW5mb3JtYXRpb24uDQoNClllcywgdGhlIElFVEYgaGFz IGEgcGxldGhvcmEgb2YgcHJvdG9jb2xzIGZvciBwZWVycyBvZiBwcm90b2NvbCBYIHRvIGV4Y2hh bmdlIGluZm9ybWF0aW9uIHdpdGggb3RoZXIgcGVlcnMsIGJ1dCBhbGwgdGhlc2UgcHJvdG9jb2xz IHJlcXVpcmVzIG9uZSBvZiB0aGUgZm9sbG93aW5nIG1lY2hhbmlzbXM6IHBvbGxpbmcsIGJyb2Fk Y2FzdCBhbm5vdW5jaW5nLCBvciBzdGF0aWMgY29uZmlndXJhdGlvbi4NCg0KRm9yIGV4YW1wbGU6 IEEgbG9jYWwgcm91dGVyIGhhcyBhbiBOVFAgc2VydmljZSB0aGF0IHdhbnRzIHRvIGZpbmQgc29t ZSB1cHN0cmVhbSBwZWVycyAob3Igd2hhdGV2ZXIgdGhleSdyZSBjYWxsZWQgaW4gTlRQLXNwZWFr KS4gIFdoZW5ldmVyIGl0IHJlY2VpdmVzIGEgRExFUCBEZXN0X1VwLCBpdCBoYXMgdG8gYXR0ZW1w dCBhbiBOVFAgc2Vzc2lvbiBqdXN0IGluIGNhc2UgdGhlIHJlbW90ZSByb3V0ZXIgaXMgYSB2YWxp ZCBwZWVyLiAgVGhpcyBpcyBIZWxsbyBhZ2FpbiwgYXQgTGF5ZXIgNCssIHJhdGhlciB0aGFuIExh eWVyIDMuIA0KDQpJZiBETEVQIGNhbiBwcm92aWRlIGxheWVyIDQrIGluZm9ybWF0aW9uIHRvIGF2 b2lkIExheWVyIDQrIEhlbGxvcywganVzdCBhcyBpdCBwcm92aWRlcyBMYXllciAzIGluZm9ybWF0 aW9uIHRvIGF2b2lkIExheWVyIDMgSGVsbG9zLCB0aGVuIEkgc2VlIHRoaXMgYXMgdXNlZnVsLiAg RXZlbiBpZiB0aGUgb25seSBzZXJ2aWNlIGFubm91bmNlZCBpcyBtRE5TLCBhbmQgbUROUyBpcyB0 aGVuIHVzZWQgZm9yIGFsbCBvdGhlciBzZXJ2aWNlIGRpc2NvdmVyeSwgdGhpcyBpcyBhbiBpbXBy b3ZlbWVudC4NCg0KPiANCj4gV2hhdCBJIGhhZCBleHBlY3RlZCBpbiB0aGlzIGRyYWZ0IHdhcyBh IHdheSBmb3IgdGhlIHJhZGlvIHRvIGFubm91bmNlIGl0cw0KPiBMT0NBTCBzZXJ2aWNlcyB0byB0 aGUgcm91dGVyLCBlLmcuIGEgU0lQIGVuZHBvaW50IHRvIGNvbm5lY3QgeW91ciByb3V0ZXJzDQo+ IFZPSVAgbmV0d29yayB0byBhIGxvY2FsbHkgZXhpc3RpbmcgInB1c2ggdG8gdGFsayIgdm9pY2Ug Y2hhbm5lbC4NCj4gT3RoZXIgZXhhbXBsZXMgd291bGQgYmUgdG8gYW5ub3VuY2UgdGhlIGV4aXN0 ZW5jZSBvZiBIVFRQIGlwL3BvcnQNCj4gKGNvbmZpZ3VyYXRpb24gR1VJKSBvciBhIG5ldGNvbmYv c3NoIHBvcnQuDQoNCkFoIHllcy4uLiAgVGhpcyBpcyBhbHNvIHZlcnkgdXNlZnVsLCBidXQgSSB3 b3VsZCBzYXkgaXQgd2FzIGEgZGlmZmVyZW50IGV4dGVuc2lvbi4gIEhvd2V2ZXIsIHRoZXJlIGhh cyBiZWVuIHNvbWUgZ2VuZXJhbCBjb25zZW5zdXMgdGhhdCBETEVQIGlzIG5vdCBhIG1hbmFnZW1l bnQgcHJvdG9jb2wsIHNvIG9uZSB3b3VsZCBoYXZlIHRvIGJlIGNhcmVmdWwgd2l0aCB3aGF0IGlz IGRlc2NyaWJlZC4gIEknbSBoYXBweSB0byBoZWxwL3Jldmlldy9jb21tZW50IG9uIGFueSBpZGVh cyB5b3UgaGF2ZS4NCg0KQXMgYW4gYXNpZGUsIHlvdSBhcmUgdGhlIHNlY29uZCBwZXJzb24gd2hv IGhhcyBjb25mbGF0ZWQgRFNBIHdpdGggd2hhdCB5b3UgZGVzY3JpYmUgLSBwZXJoYXBzIEkgbmVl ZCB0byByZXZpc2l0IHNvbWUgb2YgdGhlIHRleHQhDQoNCj4gDQo+IFRoZSBzZWNvbmQgKG1pbm9y KSBpc3N1ZSBJIGhhdmUgd2l0aCB0aGUgZHJhZnQgaXMgdGhlIHRleHQgc3RyaW5nIHVzZWQgdG8N Cj4gaWRlbnRpZnkgdGhlIHNlcnZpY2UuIEl0IGZlZWxzIGEgYml0ICJvdXQgb2YgcGxhY2UiIGlu IGFsbCB0aGUgYmluYXJ5IGVuY29kZWQgZGF0YQ0KPiBETEVQIHRyYW5zZmVycy4NCg0KR29vZCBw b2ludC4gIFRoZSB0ZXh0dWFsIGRhdGEgIGlzIGEgYml0IG9mIGEgbWlzbWF0Y2ggd2l0aCB0aGUg cmVzdCBvZiBETEVQLCBidXQgSSBjb3VsZG4ndCAoYXQgdGhlIHRpbWUpIHRoaW5rIG9mIGFuIGFs dGVybmF0aXZlIGZvcm1hdCBnZW5lcmljIGVub3VnaCB0byBjYXJyeSBhIGxvb3NlIGJ1bmRsZSBv ZiBsYXllciA0KyBwcm90b2NvbCBpbmZvcm1hdGlvbi4gIEhvd2V2ZXIsIHdoYXQgZG8gcGVvcGxl IHRoaW5rIGFib3V0IHVzaW5nIHNvbWV0aGluZyBDQk9SIGVuY29kZWQ/ICBJdCdzIGJpbmFyeSBh bmQgbW9yZSBjb25jaXNlIGFuZCBJRVRGLWlzaCwgd2hpY2ggbWVhbnMgdGhhdCByYWRpbyB2ZW5k b3JzIGNvdWxkIGNvbnNpZGVyIGp1c3Qgc2hvdmVsaW5nIGl0IG92ZXIgdGhlIGFpciwgb3IgdGhl eSBjb3VsZCBwcm94eS9jb21wcmVzcyBmYWlybHkgc2ltcGx5LiAgSSB3aWxsIGhhdmUgYSBwbGF5 IGFyb3VuZCB0byBzZWUgaWYgaXQgZml0cyBiZXR0ZXIuDQoNClRoYW5rcyBmb3IgdGhlIGZlZWRi YWNrLA0KDQpSaWNrDQo= From nobody Sat Sep 2 13:17:35 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE2D1320B5 for ; Sat, 2 Sep 2017 13:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 rlW1hkuYt2Zk for ; Sat, 2 Sep 2017 13:17:31 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC6A133033 for ; Sat, 2 Sep 2017 13:17:30 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id q64so2903491iod.5 for ; Sat, 02 Sep 2017 13:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Kmb17e+eioPhdMKvNSf8qZ6KhfNiIvEgi+tIwndbl/U=; b=FPWPGjlOhXzHrKnqob8myWp3AfaaY7TYl5NcJvuDnFOMHoEk4ZKCMVdYyymuztIU6N BSlrVEdNAuN/bx19BXtPbsqWV6nw/m5jmiupHRp7pkSgnrkEcN5nqNQFl5wAkF+HqkVI eo9KUZAy+aE/gZ/dnk6qev+GmGO7LWD/L0rSRUwMkof6qZU8ns5Yw7BEuceHiCGj5Zm1 j01B8rI7aj6UNV9JuNf+QgP7S8nxiR1fgn6vvfQBhDPCue8q2/kVZorGAbFAplThRnup a6AxZQuB1zFVULpo7qpKn7RanHxeeH6Za4QklqLUnXldkkV7Zpy8WrLC8/wRs/56WVy4 NyFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Kmb17e+eioPhdMKvNSf8qZ6KhfNiIvEgi+tIwndbl/U=; b=Ul+2jZKQzpDrYmjcBKQMLtkSaiHI4Oh/eQf0xD9xOsIPOCuq7pBJhVY7MYP1qnu27o cxoEQEd5Sozb42+t9WmzXXBO1vanW2xZVIRnbh4krkU39XE/xxa+Ou7UHTTagaUY6/Fu D3uW7yhPAXMGJNRyF1096k6u8O5++pjLXhRfLXaTFVvkEcSbDM/vQ+kPIGtVDz7kX1vj oe/HAh1YImq0hPpmKzrzUTwBwKrGRUKhtRAexTJ4PXc5jPE7bY08MBRFHNyPf5G9G1AU HGQn+ySgAHJFTFs2vqBIyfZY9Rz5o62FmugM5ALqfO2yOcnBzFVZRak1frBPoNVA+1TW Nmrg== X-Gm-Message-State: AHPjjUhwQX2M/0RQ7wCg/c6Nra4hqYDKtn7YU0c1LQdXB3NsaA+X/igO ylH8kBwswcXTL6FebSqHC0JryqhCFA== X-Google-Smtp-Source: ADKCNb4iEIZth4Rjt/sIR41tj6LRbbllZZkZjXyLCPiTmCQkThxvHJu4IkIgSBfK1sTzrBt/pHeRR2Z16zi46VnhLg0= X-Received: by 10.107.10.15 with SMTP id u15mr4376391ioi.150.1504383449472; Sat, 02 Sep 2017 13:17:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.124.138 with HTTP; Sat, 2 Sep 2017 13:17:28 -0700 (PDT) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801D30BA2E9@tss-server1.home.tropicalstormsoftware.com> References: <1500890455.2721.234.camel@tropicalstormsoftware.com> <1504171326.31980.2.camel@tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801D30BA2E9@tss-server1.home.tropicalstormsoftware.com> From: Stan Ratliff Date: Sat, 2 Sep 2017 16:17:28 -0400 Message-ID: To: Rick Taylor Cc: Henning Rogge , "manet@ietf.org" Content-Type: multipart/alternative; boundary="001a113ee8da1ca3f405583a91f3" Archived-At: Subject: Re: [manet] New DLEP extension drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2017 20:17:34 -0000 --001a113ee8da1ca3f405583a91f3 Content-Type: text/plain; charset="UTF-8" My 2-cents worth... On Sat, Sep 2, 2017 at 5:20 AM, Rick Taylor wrote: > Thanks for the comments, Henning, replies inline... > > > -----Original Message----- > > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge > > Sent: 01 September 2017 07:18 > > To: manet@ietf.org > > Subject: Re: [manet] New DLEP extension drafts > > > > Am 31.08.2017 um 11:22 schrieb Rick Taylor: > > > Hi All, > > > > Okay, time to get the ball rolling for service discovery. > > Excellent! This draft was first started 2 years ago, so bits of it are > definitely unclear/out-of-date. > > > > > I must admit I am not that happy with the draft in its current form. > > > > First reason is the that the draft focuses on announcing router services > to > > other routers. This makes it practically necessary to add an over the air > > component to DLEP. I thought we agreed that one of the design goals of > > DLEP was only to communicate between the local radio and the local > router, > > exchanging already existing local knowledge. > > Okay... I'll answer this point in parts: > a) I remember the early DLEP discussions agreed that the DLEP protocol > would not define how or what was sent over the air, but did require that > something was sent in order to function. The assumption being that nearly > all radio systems have some kind of control plane. DLEP only defines the > 'how and what format' of the local communication. > > b) Yes, this extension does require some data to be transmitted over the > air (it does not specify how or in what format, just like DLEP), but as an > extension, it is optional. > > I agree with Rick here - this is pretty much like the announcement of Layer-3 addresses and subnets. If an implementation is going to support that, some OTA transmission is implied, and required. > > > > I think DLEP is the wrong protocol to exchange knowledge between routers > > and I am sure the IETF already has protocols for the two routers > exchanging > > service information. > > Yes, the IETF has a plethora of protocols for peers of protocol X to > exchange information with other peers, but all these protocols requires one > of the following mechanisms: polling, broadcast announcing, or static > configuration. > > For example: A local router has an NTP service that wants to find some > upstream peers (or whatever they're called in NTP-speak). Whenever it > receives a DLEP Dest_Up, it has to attempt an NTP session just in case the > remote router is a valid peer. This is Hello again, at Layer 4+, rather > than Layer 3. > > If DLEP can provide layer 4+ information to avoid Layer 4+ Hellos, just as > it provides Layer 3 information to avoid Layer 3 Hellos, then I see this as > useful. Even if the only service announced is mDNS, and mDNS is then used > for all other service discovery, this is an improvement. > If, as you say, "Even if the only service announced is mDNS, and mDNS is then used..." - why not *assume* that mDNS is present, and go for it? I've gone back & forth over the notion of service announcements. I think we're going to get significant pushback from the IETF that there are already multiple protocols for service announcement, and we're just re-inventing the wheel for the 47th time. Having said that, I'm interested in being able to transmit *some* additional information at Destination Up. For example, consider a military deployment (I only use it because I've seen this implemented, and can articulate the problem). There are some vehicles that are equipped with LoS mesh radios; and there are also a few equipped with the mesh radios and a satellite terminal/dish for reach back. I'd like some way for one of the satellite-equipped "reach back guys" to be able to communicate via DLEP on the LoS mesh radio that "I have reach-back capability". To me, this information would fold into things like selection of a "Designated Router" for OSPF, or an MPR for OLSR. This is something of a "capabilities" TLV, where a "capability" (e.g., the reach back) is not necessarily a part of the radio being used. Another "capability" would be to somehow announce "I'm plugged into a reliable, 24/7 power source, so battery consumption isn't a problem". In both of these cases, they enhance the node's ability and willingness to act as a traffic relay. Regards, Stan > > > > > What I had expected in this draft was a way for the radio to announce its > > LOCAL services to the router, e.g. a SIP endpoint to connect your routers > > VOIP network to a locally existing "push to talk" voice channel. > > Other examples would be to announce the existence of HTTP ip/port > > (configuration GUI) or a netconf/ssh port. > > Ah yes... This is also very useful, but I would say it was a different > extension. However, there has been some general consensus that DLEP is not > a management protocol, so one would have to be careful with what is > described. I'm happy to help/review/comment on any ideas you have. > > As an aside, you are the second person who has conflated DSA with what you > describe - perhaps I need to revisit some of the text! > > > > > The second (minor) issue I have with the draft is the text string used to > > identify the service. It feels a bit "out of place" in all the binary > encoded data > > DLEP transfers. > > Good point. The textual data is a bit of a mismatch with the rest of > DLEP, but I couldn't (at the time) think of an alternative format generic > enough to carry a loose bundle of layer 4+ protocol information. However, > what do people think about using something CBOR encoded? It's binary and > more concise and IETF-ish, which means that radio vendors could consider > just shoveling it over the air, or they could proxy/compress fairly > simply. I will have a play around to see if it fits better. > > Thanks for the feedback, > > Rick > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a113ee8da1ca3f405583a91f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My 2-cents worth...=C2=A0


On Sat, Sep 2, 2017 at 5:20 AM, Rick Tayl= or <rick@tropicalstormsoftware.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Thanks for the comments, Henning, replies inl= ine...

> -----Original Message-----
> From: manet [mailto:manet-bo= unces@ietf.org] On Behalf Of Henning Rogge
> Sent: 01 September 2017 07:18
> To: manet@ietf.org
> Subject: Re: [manet] New DLEP extension drafts
>
> Am 31.08.2017 um 11:22 schrieb Rick Taylor:
> > Hi All,
>
> Okay, time to get the ball rolling for service discovery.

Excellent!=C2=A0 This draft was first started 2 years ago, so bits of it ar= e definitely unclear/out-of-date.

>
> I must admit I am not that happy with the draft in its current form. >
> First reason is the that the draft focuses on announcing router servic= es to
> other routers. This makes it practically necessary to add an over the = air
> component to DLEP. I thought we agreed that one of the design goals of=
> DLEP was only to communicate between the local radio and the local rou= ter,
> exchanging already existing local knowledge.

Okay... I'll answer this point in parts:
a) I remember the early DLEP discussions agreed that the DLEP protocol woul= d not define how or what was sent over the air, but did require that someth= ing was sent in order to function.=C2=A0 The assumption being that nearly a= ll radio systems have some kind of control plane.=C2=A0 DLEP only defines t= he 'how and what format' of the local communication.

b) Yes, this extension does require some data to be transmitted over the ai= r (it does not specify how or in what format, just like DLEP), but as an ex= tension, it is optional.


I agree with Rick here - this is prett= y much like the announcement of Layer-3 addresses and subnets. If an implem= entation is going to support that, some OTA transmission is implied, and re= quired.=C2=A0
=C2=A0
>
> I think DLEP is the wrong protocol to exchange knowledge between route= rs
> and I am sure the IETF already has protocols for the two routers excha= nging
> service information.

Yes, the IETF has a plethora of protocols for peers of protocol X to exchan= ge information with other peers, but all these protocols requires one of th= e following mechanisms: polling, broadcast announcing, or static configurat= ion.

For example: A local router has an NTP service that wants to find some upst= ream peers (or whatever they're called in NTP-speak).=C2=A0 Whenever it= receives a DLEP Dest_Up, it has to attempt an NTP session just in case the= remote router is a valid peer.=C2=A0 This is Hello again, at Layer 4+, rat= her than Layer 3.

If DLEP can provide layer 4+ information to avoid Layer 4+ Hellos, just as = it provides Layer 3 information to avoid Layer 3 Hellos, then I see this as= useful.=C2=A0 Even if the only service announced is mDNS, and mDNS is then= used for all other service discovery, this is an improvement.

If, as you say, "Even if the only service anno= unced is mDNS, and mDNS is then used..." - why not *assume* that mDNS = is present, and go for it?=C2=A0

I've gone bac= k & forth over the notion of service announcements. I think we're g= oing to get significant pushback from the IETF that there are already multi= ple protocols for service announcement, and we're just re-inventing the= wheel for the 47th time.

Having said that, I'= m interested in being able to transmit *some* additional information at Des= tination Up. For example, consider a military deployment (I only use it bec= ause I've seen this implemented, and can articulate the problem). There= are some vehicles that are equipped with LoS mesh radios; and there are al= so a few equipped with the mesh radios and a satellite terminal/dish for re= ach back. I'd like some way for one of the satellite-equipped "rea= ch back guys" to be able to communicate via DLEP on the LoS mesh radio= that "I have reach-back capability". To me, this information wou= ld fold into things like selection of a "Designated Router" for O= SPF, or an MPR for OLSR. This is something of a "capabilities" TL= V, where a "capability" (e.g., the reach back) is not necessarily= a part of the radio being used. Another "capability" would be to= somehow announce "I'm plugged into a reliable, 24/7 power source,= so battery consumption isn't a problem". In both of these cases, = they enhance the node's ability and willingness to act as a traffic rel= ay.=C2=A0

Regards,
Stan

=C2=A0

>
> What I had expected in this draft was a way for the radio to announce = its
> LOCAL services to the router, e.g. a SIP endpoint to connect your rout= ers
> VOIP network to a locally existing "push to talk" voice chan= nel.
> Other examples would be to announce the existence of HTTP ip/port
> (configuration GUI) or a netconf/ssh port.

Ah yes...=C2=A0 This is also very useful, but I would say it was a differen= t extension.=C2=A0 However, there has been some general consensus that DLEP= is not a management protocol, so one would have to be careful with what is= described.=C2=A0 I'm happy to help/review/comment on any ideas you hav= e.

As an aside, you are the second person who has conflated DSA with what you = describe - perhaps I need to revisit some of the text!

>
> The second (minor) issue I have with the draft is the text string used= to
> identify the service. It feels a bit "out of place" in all t= he binary encoded data
> DLEP transfers.

Good point.=C2=A0 The textual data=C2=A0 is a bit of a mismatch with the re= st of DLEP, but I couldn't (at the time) think of an alternative format= generic enough to carry a loose bundle of layer 4+ protocol information.= =C2=A0 However, what do people think about using something CBOR encoded?=C2= =A0 It's binary and more concise and IETF-ish, which means that radio v= endors could consider just shoveling it over the air, or they could proxy/c= ompress fairly simply.=C2=A0 I will have a play around to see if it fits be= tter.

Thanks for the feedback,

Rick
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--001a113ee8da1ca3f405583a91f3-- From nobody Sat Sep 2 13:54:55 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DEB132F7C for ; Sat, 2 Sep 2017 13:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 sIcfFTmxPCKm for ; Sat, 2 Sep 2017 13:54:53 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26A0F132EF5 for ; Sat, 2 Sep 2017 13:54:53 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id o63so11722209qkb.3 for ; Sat, 02 Sep 2017 13:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LYx7YdYL626p+TJoKeDqC6Rm7JXRM6gqXuNYDvZrz0I=; b=tOermB7X3G+WC/R9KbCgu3huSh5I9MQRE2oor+dy5sFh0g1y0Z/ZdVQ4Z/7DG5GmvH LLMrD2lwHmzejEyS7QoXqSzLncqjR1rNU2fWp8kUJP+00vZAejoBtYJ+8ajiyYnU4KjU KEKqyThSgAe6b24/IhAOt/W2dCJj2pgGgV/zyvodM/PJ8ZSdDXMbpBxO0Yatjk2Cov5J zdyUNw8pV913rFV1stItNejR32zYQ4K/oDOYZ8oo6MRbAIM2Jixzf+ToVqXDpDM7auLd Q/bH7BPv2TY1BxZBbO50btbaxjbwQHSCIN8EvL4XL41mNK4t8VeJTRLBgt24SbJDheks MLQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LYx7YdYL626p+TJoKeDqC6Rm7JXRM6gqXuNYDvZrz0I=; b=GD7PjnyNlFCkikdz8ug5RRqKttT2+F8NBru+2sfN0MLe1tlVfw5zCaIHN7EySS29Wu ivv7V1wQzy2BnCFFAPoh72UuLXKLUHXx4XMliznllO8JfNnNDNi+ij7pZ8sYHNvrcvAC KNvngYujp/DOT+e4Or5f3+JV1AbvLN39R78EgnqFkPbBqLC+pXF6Tq2AiFxh/l4sSwzD EPn9JqAaYAFsskyMrOduaVsWN+vC75DQ4JvVt/NTJwR5prFIkZfEW/rQ03TWjjhXgGXT xxHqT3UKU3R7hokplYmEwg2RxB1x7HFRruMlT7CQn3oZBLpa/G5Ze95Lm9YmAjmAl9eV OtEQ== X-Gm-Message-State: AHPjjUigWTVGsSNmSixhiWLOlLcuCxjuPNwWC/H1SH8OACjCYDXI9eIK swoSOv9OUP9ua06xtsdIHE6QXSqx+g== X-Google-Smtp-Source: ADKCNb7776B8ftwyzVVlpwIIdjLU+Q4gMI+y3/v658M83WokoAAG4FAj5MqsfatOS6b3VUQBA822AjJY1X0V8lu58gs= X-Received: by 10.55.31.133 with SMTP id n5mr7871803qkh.340.1504385692146; Sat, 02 Sep 2017 13:54:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.43.135 with HTTP; Sat, 2 Sep 2017 13:54:21 -0700 (PDT) In-Reply-To: References: <1500890455.2721.234.camel@tropicalstormsoftware.com> <1504171326.31980.2.camel@tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801D30BA2E9@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Sat, 2 Sep 2017 22:54:21 +0200 Message-ID: To: Stan Ratliff Cc: Rick Taylor , "manet@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [manet] New DLEP extension drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2017 20:54:55 -0000 On Sat, Sep 2, 2017 at 10:17 PM, Stan Ratliff wrote: > My 2-cents worth... > > > I agree with Rick here - this is pretty much like the announcement of > Layer-3 addresses and subnets. If an implementation is going to support > that, some OTA transmission is implied, and required. What is even the advantage moving "router to router" communication to DLEP? I can see the point of IP address propagation, especially on radios without multicast support. Without the unicast IP of the other side you cannot reach it. But for supporting services putting it into DLEP is no advantage at all... you could easily just let the routers exchange the information directly. > If, as you say, "Even if the only service announced is mDNS, and mDNS is > then used..." - why not *assume* that mDNS is present, and go for it? > > I've gone back & forth over the notion of service announcements. I think > we're going to get significant pushback from the IETF that there are already > multiple protocols for service announcement, and we're just re-inventing the > wheel for the 47th time. That too. > Having said that, I'm interested in being able to transmit *some* additional > information at Destination Up. For example, consider a military deployment > (I only use it because I've seen this implemented, and can articulate the > problem). There are some vehicles that are equipped with LoS mesh radios; > and there are also a few equipped with the mesh radios and a satellite > terminal/dish for reach back. I'd like some way for one of the > satellite-equipped "reach back guys" to be able to communicate via DLEP on > the LoS mesh radio that "I have reach-back capability". To me, this > information would fold into things like selection of a "Designated Router" > for OSPF, or an MPR for OLSR. This is something of a "capabilities" TLV, > where a "capability" (e.g., the reach back) is not necessarily a part of the > radio being used. Another "capability" would be to somehow announce "I'm > plugged into a reliable, 24/7 power source, so battery consumption isn't a > problem". In both of these cases, they enhance the node's ability and > willingness to act as a traffic relay. Capability might also include "need unicast traffic for datarate selection". Henning From nobody Mon Sep 4 14:47:22 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03EAF132143 for ; Mon, 4 Sep 2017 14:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 tDl4jitXWVVh for ; Mon, 4 Sep 2017 14:47:20 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A96132139 for ; Mon, 4 Sep 2017 14:47:19 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Mon, 4 Sep 2017 22:46:55 +0100 From: Rick Taylor To: Henning Rogge , Stan Ratliff CC: "manet@ietf.org" Thread-Topic: [manet] New DLEP extension drafts Thread-Index: AQHTIjqdj1aPXRKHkUWtp7lq2oY7e6Kffs2AgAHOTrCAAK6rAIAACk6AgAM6jKA= Date: Mon, 4 Sep 2017 21:46:54 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801D30BD277@tss-server1.home.tropicalstormsoftware.com> References: <1500890455.2721.234.camel@tropicalstormsoftware.com> <1504171326.31980.2.camel@tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801D30BA2E9@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] New DLEP extension drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 21:47:22 -0000 Umlwb3N0ZXMgaW5saW5lLi4uDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogSGVubmluZyBSb2dnZSBbbWFpbHRvOmhyb2dnZUBnbWFpbC5jb21dDQo+IFNlbnQ6IDAyIFNl cHRlbWJlciAyMDE3IDIxOjU0DQo+IFRvOiBTdGFuIFJhdGxpZmYNCj4gQ2M6IFJpY2sgVGF5bG9y OyBtYW5ldEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW21hbmV0XSBOZXcgRExFUCBleHRlbnNp b24gZHJhZnRzDQo+IA0KPiBPbiBTYXQsIFNlcCAyLCAyMDE3IGF0IDEwOjE3IFBNLCBTdGFuIFJh dGxpZmYgPHJhdGxpZmZzdGFuQGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4gTXkgMi1jZW50cyB3b3J0 aC4uLg0KPiA+DQo+ID4NCj4gPiBJIGFncmVlIHdpdGggUmljayBoZXJlIC0gdGhpcyBpcyBwcmV0 dHkgbXVjaCBsaWtlIHRoZSBhbm5vdW5jZW1lbnQgb2YNCj4gPiBMYXllci0zIGFkZHJlc3NlcyBh bmQgc3VibmV0cy4gSWYgYW4gaW1wbGVtZW50YXRpb24gaXMgZ29pbmcgdG8NCj4gPiBzdXBwb3J0 IHRoYXQsIHNvbWUgT1RBIHRyYW5zbWlzc2lvbiBpcyBpbXBsaWVkLCBhbmQgcmVxdWlyZWQuDQo+ IA0KPiBXaGF0IGlzIGV2ZW4gdGhlIGFkdmFudGFnZSBtb3ZpbmcgInJvdXRlciB0byByb3V0ZXIi IGNvbW11bmljYXRpb24gdG8NCj4gRExFUD8NCg0KVGhlIG1ham9yIGFkdmFudGFnZSBJIGNhbiBz ZWUgaXMgZmFzdCAnZWRnZSB0cmlnZ2VyZWQnIGFkamFjZW5jeSBmb3JtYXRpb24uICBUaGlzIGlz IG9uZSBvZiB0aGUgc2VsbGluZyBwb2ludHMgb2YgRExFUCBmb3IgTGF5ZXIgMywgc28gd2h5IG5v dCBleHBvc2UgTGF5ZXIgNCsgdHJpZ2dlcnMgYXMgd2VsbC4gIEdpdmVuIEkgd29yayBmb3IgYSBj b21wYW55IHdob3NlIHZlaGljbGVzIG1vdmUgYXQgc29tZSBzcGVlZCwgYmVpbmcgYWJsZSB0byBm b3JtIGFuIGFkamFjZW5jeSBiZXR3ZWVuIHBlZXIgc2VydmljZXMgZmFzdCBpcyBoZWxwZnVsLiAg SWYgSSBoYXZlIGEgdHJhbnNtaXNzaW9uIHdpbmRvdyBvZiAxIG1pbnV0ZSBtYXgsIEkgZG9uJ3Qg d2FudCB0byBzcGVuZCB0aGUgZmlyc3QgMzAgc2Vjb25kcyBIZWxsbydpbmcgd2l0aCBldmVyeSBw cm90b2NvbCB0aGF0IG1pZ2h0IHdhbnQgdG8gZmluZCBhIHBlZXIgb3ZlciB0aGUgcG9zc2libHkg cmVzdHJpY3RlZC9mbGFrZXkgbGluay4gDQoNCj4gDQo+IEkgY2FuIHNlZSB0aGUgcG9pbnQgb2Yg SVAgYWRkcmVzcyBwcm9wYWdhdGlvbiwgZXNwZWNpYWxseSBvbiByYWRpb3Mgd2l0aG91dA0KPiBt dWx0aWNhc3Qgc3VwcG9ydC4gV2l0aG91dCB0aGUgdW5pY2FzdCBJUCBvZiB0aGUgb3RoZXIgc2lk ZSB5b3UgY2Fubm90IHJlYWNoDQo+IGl0Lg0KPiANCj4gQnV0IGZvciBzdXBwb3J0aW5nIHNlcnZp Y2VzIHB1dHRpbmcgaXQgaW50byBETEVQIGlzIG5vIGFkdmFudGFnZSBhdCBhbGwuLi4geW91DQo+ IGNvdWxkIGVhc2lseSBqdXN0IGxldCB0aGUgcm91dGVycyBleGNoYW5nZSB0aGUgaW5mb3JtYXRp b24gZGlyZWN0bHkuDQoNCkknbSBub3Qgc3VnZ2VzdGluZyBtb3Zpbmcvd3JhcHBpbmcgdGhlIHNl cnZpY2UgcHJvdG9jb2wgaW4gRExFUCwganVzdCB0aGUga25vd2xlZGdlIHRoYXQgaXQncyBldmVu IHdvcnRoIHRyeWluZyB0byBiZWdpbiBpdC4NCg0KPiANCj4gPiBJZiwgYXMgeW91IHNheSwgIkV2 ZW4gaWYgdGhlIG9ubHkgc2VydmljZSBhbm5vdW5jZWQgaXMgbUROUywgYW5kIG1ETlMNCj4gPiBp cyB0aGVuIHVzZWQuLi4iIC0gd2h5IG5vdCAqYXNzdW1lKiB0aGF0IG1ETlMgaXMgcHJlc2VudCwg YW5kIGdvIGZvciBpdD8NCg0KSGFoYS4uLiB5b3Uga25vdyB0aGUgYW5zd2VyIGFzIHdlbGwgYXMg SSBkby4gIFNvbWVvbmUgd2lsbCBzYXkgdGhleSBkb24ndCB1c2UgbUROUywgdGhleSB1c2Ugd2hh dCB0aGV5IGNvbnNpZGVyIGJldHRlci4gIEkgY291bGRuJ3QgYmUgc28gYm9sZCBhcyB0byBzdWdn ZXN0IG1ETlMgYXMgYSBvbmUgc2l6ZSBmaXRzIGFsbCBzb2x1dGlvbi4gIFRoaXMgaXMgdGhlIElF VEYhDQoNCj4gPg0KPiA+IEkndmUgZ29uZSBiYWNrICYgZm9ydGggb3ZlciB0aGUgbm90aW9uIG9m IHNlcnZpY2UgYW5ub3VuY2VtZW50cy4gSQ0KPiA+IHRoaW5rIHdlJ3JlIGdvaW5nIHRvIGdldCBz aWduaWZpY2FudCBwdXNoYmFjayBmcm9tIHRoZSBJRVRGIHRoYXQgdGhlcmUNCj4gPiBhcmUgYWxy ZWFkeSBtdWx0aXBsZSBwcm90b2NvbHMgZm9yIHNlcnZpY2UgYW5ub3VuY2VtZW50LCBhbmQgd2Un cmUNCj4gPiBqdXN0IHJlLWludmVudGluZyB0aGUgd2hlZWwgZm9yIHRoZSA0N3RoIHRpbWUuDQo+ IA0KPiBUaGF0IHRvby4NCj4NCg0KSSBxdWl0ZSBhZ3JlZS4uLiBJJ20gZXhwZWN0aW5nIGxlZ2l0 aW1hdGUgcHVzaC1iYWNrLCBJIGp1c3QgZmVlbCB0aGVyZSBpcyBhIG1pc3NpbmcgcGllY2UgaGVy ZS4gIFRoaXMgaXMgd2h5IG15IGZpcnN0IHBhc3Mgd2FzIHNpbXBseSB0byBhbm5vdW5jZSB0dXBs ZXMgb2YgW3NlcnZpY2UsIGFkZHJlc3MsIHBvcnRdIGFuZCBub3QgbXVjaCBlbHNlLiAgSXQgc2hv dWxkIGJlIGVub3VnaCB0byBib290c3RyYXAgd2hhdGV2ZXIgc2VydmljZSB5b3UncmUgcnVubmlu Zy4gIEFjdHVhbGx5IHdoYXQncyBkZXNjcmliZWQgaW4gRFNBIGlzIHZlcnkgY2xvc2UgdG8gRE5T IFNSViByZWNvcmRzLCBoZW5jZSB0aGUgdGV4dCBmb3JtLg0KDQpPbmUgcmVhc29uIHdoeSBjb3Jl IERMRVAgaXMgbm90IHF1aXRlIGdvb2QgZW5vdWdoIG1pZ2h0IGJlIHRoYXQgYSByZW1vdGUgcm91 dGVyIG1pZ2h0IG9ubHkgYmUgcnVubmluZyBhIGdpdmVuIHNlcnZpY2UgKHNheSBOVFApIGJvdW5k IHRvIGEgbG9vcGJhY2sgaW50ZXJmYWNlLiAgVGhlIERMRVAgRGVzdF9VcCBtYXkgaW5jbHVkZSB0 aGUgbG9vcGJhY2sgYWRkcmVzcyBhcyBwYXJ0IG9mIHRoZSBJUCBhZGRyZXNzIGRhdGEgaXRlbXMg aW4gdGhlIG1lc3NhZ2UsIGJ1dCBhbnkgcG90ZW50aWFsIHBlZXIgaXMgZ29pbmcgdG8gaGF2ZSB0 byBwcm9iZSBldmVyeSByZXBvcnRlZCBhZGRyZXNzIHVudGlsIGl0IGZpbmRzIHRoZSBvbmUgdGhh dCB3b3JrcywgaWYgYW55Lg0KDQpJIGtlZXAgcGlja2luZyBOVFAgYXMgdGhlIGV4YW1wbGUgc2Vy dmljZSBhcyBpdCBpcyBhbiBhLXByaW9yaSBjb25maWd1cmVkIHByb3RvY29sICh1bmxlc3MgdGhl cmUgaXMgYW4gZXhjaXRpbmcgTlRQIHBlZXIgZGlzY292ZXJ5IHByb3RvY29sIEkgZG9uJ3Qga25v dyBhYm91dCkuICBGb3Igc2VydmljZXMgdGhhdCBoYXZlIGEgZGlzY292ZXJ5IHByb3RvY29sIChl LmcuIE9MU1J2MiksIERTQSBpcyBvdmVya2lsbCwgZm9yIHN0YXRpYyBJIGZlZWwgaXQncyBsZXNz IGNsZWFyIGN1dC4NCg0KV2hlcmUgYWRkaXRpb25hbCBjb25maWcgZGF0YSBiZXlvbmQgW3NlcnZp Y2UsYWRkcmVzcyxwb3J0XSBtaWdodCBiZSB1c2VmdWwgaXMgZm9yIHNvbWV0aGluZyBsaWtlIEJH UCBBUyBudW1iZXIsIGJ1dCB0aGUgY291bnRlci1hcmd1bWVudCBjb3VsZCBiZSB0aGF0IHlvdSBv bmx5IG5lZWQgdG8gYWR2ZXJ0aXNlIDEgdHVwbGU6IFtORVRDT05GLGFkZHJdICA7LSkNCg0KSSB0 aGluayBhbnkgbGF0ZXIgcmV2aXNpb24gd2lsbCBoYXZlIHRvIGJlIGxpYmVyYWxseSBzcHJpbmts ZWQgd2l0aCB0ZXh0IHRoYXQgd2FybnMgdGhhdCB0aGlzIGV4dGVuc2lvbiBpcyBvbmx5IGZvciBi b290c3RyYXBwaW5nLCBub3QgZm9yIHByb3RvY29sIHBhcmFtZXRlciBuZWdvdGlhdGlvbi4NCg0K PiA+IEhhdmluZyBzYWlkIHRoYXQsIEknbSBpbnRlcmVzdGVkIGluIGJlaW5nIGFibGUgdG8gdHJh bnNtaXQgKnNvbWUqDQo+ID4gYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhdCBEZXN0aW5hdGlvbiBV cC4gRm9yIGV4YW1wbGUsIGNvbnNpZGVyIGENCj4gPiBtaWxpdGFyeSBkZXBsb3ltZW50IChJIG9u bHkgdXNlIGl0IGJlY2F1c2UgSSd2ZSBzZWVuIHRoaXMgaW1wbGVtZW50ZWQsDQo+ID4gYW5kIGNh biBhcnRpY3VsYXRlIHRoZSBwcm9ibGVtKS4gVGhlcmUgYXJlIHNvbWUgdmVoaWNsZXMgdGhhdCBh cmUNCj4gPiBlcXVpcHBlZCB3aXRoIExvUyBtZXNoIHJhZGlvczsgYW5kIHRoZXJlIGFyZSBhbHNv IGEgZmV3IGVxdWlwcGVkIHdpdGgNCj4gPiB0aGUgbWVzaCByYWRpb3MgYW5kIGEgc2F0ZWxsaXRl IHRlcm1pbmFsL2Rpc2ggZm9yIHJlYWNoIGJhY2suIEknZCBsaWtlDQo+ID4gc29tZSB3YXkgZm9y IG9uZSBvZiB0aGUgc2F0ZWxsaXRlLWVxdWlwcGVkICJyZWFjaCBiYWNrIGd1eXMiIHRvIGJlDQo+ ID4gYWJsZSB0byBjb21tdW5pY2F0ZSB2aWEgRExFUCBvbiB0aGUgTG9TIG1lc2ggcmFkaW8gdGhh dCAiSSBoYXZlDQo+ID4gcmVhY2gtYmFjayBjYXBhYmlsaXR5Ii4gVG8gbWUsIHRoaXMgaW5mb3Jt YXRpb24gd291bGQgZm9sZCBpbnRvIHRoaW5ncyBsaWtlDQo+IHNlbGVjdGlvbiBvZiBhICJEZXNp Z25hdGVkIFJvdXRlciINCj4gPiBmb3IgT1NQRiwgb3IgYW4gTVBSIGZvciBPTFNSLiBUaGlzIGlz IHNvbWV0aGluZyBvZiBhICJjYXBhYmlsaXRpZXMiDQo+ID4gVExWLCB3aGVyZSBhICJjYXBhYmls aXR5IiAoZS5nLiwgdGhlIHJlYWNoIGJhY2spIGlzIG5vdCBuZWNlc3NhcmlseSBhDQo+ID4gcGFy dCBvZiB0aGUgcmFkaW8gYmVpbmcgdXNlZC4gQW5vdGhlciAiY2FwYWJpbGl0eSIgd291bGQgYmUg dG8gc29tZWhvdw0KPiA+IGFubm91bmNlICJJJ20gcGx1Z2dlZCBpbnRvIGEgcmVsaWFibGUsIDI0 LzcgcG93ZXIgc291cmNlLCBzbyBiYXR0ZXJ5DQo+ID4gY29uc3VtcHRpb24gaXNuJ3QgYSBwcm9i bGVtIi4gSW4gYm90aCBvZiB0aGVzZSBjYXNlcywgdGhleSBlbmhhbmNlIHRoZQ0KPiA+IG5vZGUn cyBhYmlsaXR5IGFuZCB3aWxsaW5nbmVzcyB0byBhY3QgYXMgYSB0cmFmZmljIHJlbGF5Lg0KDQpJ IHNoYXJlIHlvdXIgdXNlLWNhc2VzLCBidXQgSSB0aGluayB5b3UncmUgaW4gZGFuZ2VyIG9mIGNv bmZsYXRpbmcgbG9jYWwgcmFkaW8gY2FwYWJpbGl0eSAod2hhdCBIZW5uaW5nIHdhcyBkZXNpcmlu ZykgYW5kIHJlbW90ZSByb3V0ZXIgY2FwYWJpbGl0eSwgYnV0IHRoYXQncyBub3QgdG8gc2F5IEkg ZG9uJ3QgbGlrZSB0aGUgaWRlYSBvZiBib3RoLCBJJ20ganVzdCB0cnlpbmcgdG8ga2VlcCB0aGUg c2NvcGUgbWFuYWdlYWJsZS4NCg0KPiANCj4gQ2FwYWJpbGl0eSBtaWdodCBhbHNvIGluY2x1ZGUg Im5lZWQgdW5pY2FzdCB0cmFmZmljIGZvciBkYXRhcmF0ZSBzZWxlY3Rpb24iLg0KDQpUaGF0J3Mg YSBnb29kIGNhcGFiaWxpdHksIGJ1dCBJIGNvbnNpZGVyIHRoYXQgbW9yZSBsb2NhbCBub3QgcmVt b3RlLiAgSSB0aGluayAiWW91IG5lZWQgdG8gdXNlIHRoZSBsaW5rIGJlZm9yZSB0aGUgQ0RSIGdv ZXMgYWJvdmUgMCIgaXMgc29tZXRoaW5nIHRoZSBsb2NhbCBtb2RlbSBzaG91bGQga25vdy4NCg0K TGV0J3Mga2VlcCB0aGUgY29udmVyc2F0aW9uIGdvaW5nLCBJIHRoaW5rIHRoZXJlIGlzIHNvbWUg dmFsdWUgaW4gaGVyZSBzb21ld2hlcmUhDQoNClJpY2sNCg== From nobody Tue Sep 5 00:52:04 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A84132644 for ; Tue, 5 Sep 2017 00:51:59 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam_report: ...that system for details.\n \n Content previ[...] X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 YvL4t_Uf4tai for ; Tue, 5 Sep 2017 00:51:55 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D791326DF for ; Tue, 5 Sep 2017 00:51:54 -0700 (PDT) Received: from rufsun5.fkie.fraunhofer.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1dp8eF-0006r2-NF for manet@ietf.org; Tue, 05 Sep 2017 09:51:52 +0200 Received: from srv-mail-01.fkie.fraunhofer.de ([128.7.11.16] helo=srv-mail-01.gaia.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dp8eF-0005BE-Kr for manet@ietf.org; Tue, 05 Sep 2017 09:51:51 +0200 Received: from [10.71.67.24] (128.7.89.212) by srv-mail-01.gaia.fkie.fraunhofer.de (128.7.11.16) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 5 Sep 2017 09:51:49 +0200 To: References: <1500890455.2721.234.camel@tropicalstormsoftware.com> <1504171326.31980.2.camel@tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801D30BA2E9@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801D30BD277@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Message-ID: <275b3ace-23c6-7db1-3bb8-07dbafdde5d5@fkie.fraunhofer.de> Date: Tue, 5 Sep 2017 09:51:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801D30BD277@tss-server1.home.tropicalstormsoftware.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [128.7.89.212] X-ClientProxiedBy: srv-mail-01.gaia.fkie.fraunhofer.de (128.7.11.16) To srv-mail-01.gaia.fkie.fraunhofer.de (128.7.11.16) X-Virus-Scanned: yes (ClamAV 0.99.2/23774/Tue Sep 5 06:34:50 2017) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 00b54f98fe2f0cea78af7465bd8f318d X-Spam_score: -1.0 X-Spam_score_int: -9 X-Spam_bar: - X-Spam_report: Spam detection software, running on the system "mailguard.fkie.fraunhofer.de", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Am 04.09.2017 um 23:46 schrieb Rick Taylor: > Ripostes inline... >> What is even the advantage moving "router to router" communication >> to DLEP? > > The major advantage I can see is fast 'edge triggered' adjacency > formation. This is one of the selling points of DLEP for Layer 3, so > why not expose Layer 4+ triggers as well. Given I work for a company > whose vehicles move at some speed, being able to form an adjacency > between peer services fast is helpful. If I have a transmission > window of 1 minute max, I don't want to spend the first 30 seconds > Hello'ing with every protocol that might want to find a peer over the > possibly restricted/flakey link. [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SHORTCIRCUIT Not all rules were run, due to a shortcircuited rule -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-ASN: Archived-At: Subject: Re: [manet] New DLEP extension drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 07:51:59 -0000 Am 04.09.2017 um 23:46 schrieb Rick Taylor: > Ripostes inline... >> What is even the advantage moving "router to router" communication >> to DLEP? > > The major advantage I can see is fast 'edge triggered' adjacency > formation. This is one of the selling points of DLEP for Layer 3, so > why not expose Layer 4+ triggers as well. Given I work for a company > whose vehicles move at some speed, being able to form an adjacency > between peer services fast is helpful. If I have a transmission > window of 1 minute max, I don't want to spend the first 30 seconds > Hello'ing with every protocol that might want to find a peer over the > possibly restricted/flakey link. You could easily use the existing layer2/layer3 'edge trigger' to start a UDP (unicast?) based service discovery for the new neighbor. No need to relay the data over the radio. >> I can see the point of IP address propagation, especially on radios >> without multicast support. Without the unicast IP of the other side >> you cannot reach it. >> >> But for supporting services putting it into DLEP is no advantage at >> all... you could easily just let the routers exchange the >> information directly. > > I'm not suggesting moving/wrapping the service protocol in DLEP, just > the knowledge that it's even worth trying to begin it. >>> If, as you say, "Even if the only service announced is mDNS, and >>> mDNS is then used..." - why not *assume* that mDNS is present, >>> and go for it? > > Haha... you know the answer as well as I do. Someone will say they > don't use mDNS, they use what they consider better. I couldn't be so > bold as to suggest mDNS as a one size fits all solution. This is the > IETF! Which is another reason not to put another solution for the same problem into DLEP, because people will not be happy with it anyways. >>> I've gone back & forth over the notion of service announcements. >>> I think we're going to get significant pushback from the IETF >>> that there are already multiple protocols for service >>> announcement, and we're just re-inventing the wheel for the 47th >>> time. >> >> That too. >> > > I quite agree... I'm expecting legitimate push-back, I just feel > there is a missing piece here. This is why my first pass was simply > to announce tuples of [service, address, port] and not much else. It > should be enough to bootstrap whatever service you're running. > Actually what's described in DSA is very close to DNS SRV records, > hence the text form. DLEP trigger for an existing DNS-based service discovery? > One reason why core DLEP is not quite good enough might be that a > remote router might only be running a given service (say NTP) bound > to a loopback interface. Are we talking about a node with routing or just a layer-2 endpoint? > The DLEP Dest_Up may include the loopback > address as part of the IP address data items in the message, but any > potential peer is going to have to probe every reported address until > it finds the one that works, if any. > > I keep picking NTP as the example service as it is an a-priori > configured protocol (unless there is an exciting NTP peer discovery > protocol I don't know about). For services that have a discovery > protocol (e.g. OLSRv2), DSA is overkill, for static I feel it's less > clear cut. Routing must do its own discovery because it has to work before Ip routing is finished. ;) As soon as we have normal connectivity, > Where additional config data beyond [service,address,port] might be > useful is for something like BGP AS number, but the counter-argument > could be that you only need to advertise 1 tuple: [NETCONF,addr] > ;-) > > I think any later revision will have to be liberally sprinkled with > text that warns that this extension is only for bootstrapping, not > for protocol parameter negotiation. Which sounds like a hint that we still have to work on the concept. I see the "necessary" use-case for announcing IPs... radios/modems/networks that can not multicast/broadcast. They are a pain, but they exist... you need the IP of the other side to do "automatic discovery". In fact, NHDP works quite fine over networks like this if you know the IPs of the other router. >>> Having said that, I'm interested in being able to transmit >>> *some* additional information at Destination Up. For example, >>> consider a military deployment (I only use it because I've seen >>> this implemented, and can articulate the problem). There are some >>> vehicles that are equipped with LoS mesh radios; and there are >>> also a few equipped with the mesh radios and a satellite >>> terminal/dish for reach back. I'd like some way for one of the >>> satellite-equipped "reach back guys" to be able to communicate >>> via DLEP on the LoS mesh radio that "I have reach-back >>> capability". To me, this information would fold into things like >> selection of a "Designated Router" >>> for OSPF, or an MPR for OLSR. This is something of a >>> "capabilities" TLV, where a "capability" (e.g., the reach back) >>> is not necessarily a part of the radio being used. Both OSPF and OLSR(v2) already work fine without any service discovery... you can make them work faster by using "triggered Hello/TC messages", e.g. triggered by Destination Up messages of DLEP. My problem with this "use DLEP as transparent router to router communication" is that it breaks a major design goal of DLEP that I (we?) told a lot of people... the advantage of DLEP is that it does not introduce additional over-the-air traffic. The radio exports everything it knows and everything it can already do for you. >>> Another >>> "capability" would be to somehow announce "I'm plugged into a >>> reliable, 24/7 power source, so battery consumption isn't a >>> problem". In both of these cases, they enhance the node's ability >>> and willingness to act as a traffic relay. > > I share your use-cases, but I think you're in danger of conflating > local radio capability (what Henning was desiring) and remote router > capability, but that's not to say I don't like the idea of both, I'm > just trying to keep the scope manageable. >> Capability might also include "need unicast traffic for datarate >> selection". > > That's a good capability, but I consider that more local not remote. > I think "You need to use the link before the CDR goes above 0" is > something the local modem should know. Yes, it is. A "I cannot to multicast/broadcast" capability flag would also be a major help for some radios. > Let's keep the conversation going, I think there is some value in > here somewhere! I think so too. Henning -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Zanderstrasse 5, 53177 Bonn, Germany Telefon +49 228 50212-469 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From nobody Tue Sep 5 02:35:06 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FC813239A for ; Tue, 5 Sep 2017 02:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ijyk7CxIOrio for ; Tue, 5 Sep 2017 02:35:03 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A12F13219C for ; Tue, 5 Sep 2017 02:35:02 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 5 Sep 2017 10:34:38 +0100 From: Rick Taylor To: "henning.rogge@fkie.fraunhofer.de" , "manet@ietf.org" , "ratliffstan@gmail.com" Thread-Topic: [manet] New DLEP extension drafts Thread-Index: AQHTIjqdj1aPXRKHkUWtp7lq2oY7e6Kffs2AgAHOTrCAAK6rAIAACk6AgAM6jKCAAKHNgIAAHF0A Date: Tue, 5 Sep 2017 09:33:18 +0000 Message-ID: <1504603998.15735.9.camel@tropicalstormsoftware.com> References: <1500890455.2721.234.camel@tropicalstormsoftware.com> <1504171326.31980.2.camel@tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801D30BA2E9@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801D30BD277@tss-server1.home.tropicalstormsoftware.com> <275b3ace-23c6-7db1-3bb8-07dbafdde5d5@fkie.fraunhofer.de> In-Reply-To: <275b3ace-23c6-7db1-3bb8-07dbafdde5d5@fkie.fraunhofer.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] New DLEP extension drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 09:35:05 -0000 SW5saW5lIGFzIHVzdWFsLi4uDQoNCk9uIFR1ZSwgMjAxNy0wOS0wNSBhdCAwOTo1MSArMDIwMCwg SGVubmluZyBSb2dnZSB3cm90ZToNCj4gQW0gMDQuMDkuMjAxNyB1bSAyMzo0NiBzY2hyaWViIFJp Y2sgVGF5bG9yOg0KPiA+IFJpcG9zdGVzIGlubGluZS4uLg0KPiA+ID4gV2hhdCBpcyBldmVuIHRo ZSBhZHZhbnRhZ2UgbW92aW5nICJyb3V0ZXIgdG8gcm91dGVyIg0KPiA+ID4gY29tbXVuaWNhdGlv bg0KPiA+ID4gdG8gRExFUD8NCj4gPiANCj4gPiBUaGUgbWFqb3IgYWR2YW50YWdlIEkgY2FuIHNl ZSBpcyBmYXN0ICdlZGdlIHRyaWdnZXJlZCcgYWRqYWNlbmN5DQo+ID4gZm9ybWF0aW9uLsKgwqBU aGlzIGlzIG9uZSBvZiB0aGUgc2VsbGluZyBwb2ludHMgb2YgRExFUCBmb3IgTGF5ZXIgMywNCj4g PiBzbw0KPiA+IHdoeSBub3QgZXhwb3NlIExheWVyIDQrIHRyaWdnZXJzIGFzIHdlbGwuwqDCoEdp dmVuIEkgd29yayBmb3IgYQ0KPiA+IGNvbXBhbnkNCj4gPiB3aG9zZSB2ZWhpY2xlcyBtb3ZlIGF0 IHNvbWUgc3BlZWQsIGJlaW5nIGFibGUgdG8gZm9ybSBhbiBhZGphY2VuY3kNCj4gPiBiZXR3ZWVu IHBlZXIgc2VydmljZXMgZmFzdCBpcyBoZWxwZnVsLsKgwqBJZiBJIGhhdmUgYSB0cmFuc21pc3Np b24NCj4gPiB3aW5kb3cgb2YgMSBtaW51dGUgbWF4LCBJIGRvbid0IHdhbnQgdG8gc3BlbmQgdGhl IGZpcnN0IDMwIHNlY29uZHMNCj4gPiBIZWxsbydpbmcgd2l0aCBldmVyeSBwcm90b2NvbCB0aGF0 IG1pZ2h0IHdhbnQgdG8gZmluZCBhIHBlZXIgb3Zlcg0KPiA+IHRoZQ0KPiA+IHBvc3NpYmx5IHJl c3RyaWN0ZWQvZmxha2V5IGxpbmsuDQo+IA0KPiBZb3UgY291bGQgZWFzaWx5IHVzZSB0aGUgZXhp c3RpbmcgbGF5ZXIyL2xheWVyMyAnZWRnZSB0cmlnZ2VyJyB0bw0KPiBzdGFydA0KPiBhIFVEUCAo dW5pY2FzdD8pIGJhc2VkIHNlcnZpY2UgZGlzY292ZXJ5IGZvciB0aGUgbmV3IG5laWdoYm9yLiBO bw0KPiBuZWVkDQo+IHRvIHJlbGF5IHRoZSBkYXRhIG92ZXIgdGhlIHJhZGlvLg0KDQpZZXMsIEkg YWdyZWUsIHlvdSBjYW4sIGFuZCBJIGRvLiAgTXkgcm91dGVycyB3aWxsIHVzZSBETEVQIGV2ZW50 cyB0bw0Ka2ljayBvZmYgYSBwcm9wcmlldGFyeSBzZXJ2aWNlIGRpc2NvdmVyeSBwcm90b2NvbCBi ZXR3ZWVuIHBlZXJzLCBhbmQgaXQNCndvcmtzIGJlYXV0aWZ1bGx5LiAgSG93ZXZlciwgaXQgb25s eSB3b3JrcyBiZXR3ZWVuIG15IHJvdXRlcnMuICBXaGVuIGENCnBlZXIgaXMgYSBDaXNjbywgb3Ig YW4gT3BlbldSVCByb3V0ZXIsIG9yIHdoYXRldmVyLCB0aGVuIEkgaGF2ZSB0byBmYWxsDQpiYWNr IHRvIHBlci1zZXJ2aWNlIHByb2JpbmcuDQoNCkkgYWxzbyBrbm93IENpc2NvIGhhdmUgcHJldmlv dXNseSBwbGF5ZWQgd2l0aCBlbWJlZGRpbmcNCnNlcnZpY2UvY2FwYWJpbGl0eSBkYXRhIGluIEVJ R1JQIGFuZCB1c2luZyB0aGF0IGluIGEgc2ltaWxhciB3YXkuDQoNCkluIGFsbCBob25lc3R5LCB0 aGVyZSBpcyBub3RoaW5nIGJpZyBvciBjbGV2ZXIgYWJvdXQgbXkgc2VydmljZQ0KZGlzY292ZXJ5 IChpdCBsb29rcyBhIGxvdCBsaWtlIERTQSwgYnV0IHdpdGggc29tZSBzZXNzaW9uIG1haW50ZW5h bmNlDQptZXNzYWdlcykuICBXaGVuIEkgd2FzIGxhc3QgcmV2aWV3aW5nIHRoZSBkZXNpZ24gZm9y IHRoaXMgaXQgb2NjdXJyZWQNCnRvIG1lIHRoYXQgaXQgd291bGQgbWFrZSBtb3JlIHNlbnNlIHRv IHJlLXVzZSB0aGUgZXhpc3RpbmcgRExFUCBzZXNzaW9uDQp0byBjYXJyeSB0aGlzIGV4dHJhIGlu Zm9ybWF0aW9uLCBoZW5jZSB0aGUgRFNBIGV4dGVuc2lvbiBkcmFmdC4NCg0KPiANCj4gPiA+IEkg Y2FuIHNlZSB0aGUgcG9pbnQgb2YgSVAgYWRkcmVzcyBwcm9wYWdhdGlvbiwgZXNwZWNpYWxseSBv bg0KPiA+ID4gcmFkaW9zDQo+ID4gPiB3aXRob3V0IG11bHRpY2FzdCBzdXBwb3J0LiBXaXRob3V0 IHRoZSB1bmljYXN0IElQIG9mIHRoZSBvdGhlcg0KPiA+ID4gc2lkZQ0KPiA+ID4geW91IGNhbm5v dCByZWFjaCBpdC4NCj4gPiA+IA0KPiA+ID4gQnV0IGZvciBzdXBwb3J0aW5nIHNlcnZpY2VzIHB1 dHRpbmcgaXQgaW50byBETEVQIGlzIG5vIGFkdmFudGFnZQ0KPiA+ID4gYXQNCj4gPiA+IGFsbC4u LiB5b3UgY291bGQgZWFzaWx5IGp1c3QgbGV0IHRoZSByb3V0ZXJzIGV4Y2hhbmdlIHRoZQ0KPiA+ ID4gaW5mb3JtYXRpb24gZGlyZWN0bHkuDQo+ID4gDQo+ID4gSSdtIG5vdCBzdWdnZXN0aW5nIG1v dmluZy93cmFwcGluZyB0aGUgc2VydmljZSBwcm90b2NvbCBpbiBETEVQLA0KPiA+IGp1c3QNCj4g PiB0aGUga25vd2xlZGdlIHRoYXQgaXQncyBldmVuIHdvcnRoIHRyeWluZyB0byBiZWdpbiBpdC4N Cj4gPiA+ID4gSWYsIGFzIHlvdSBzYXksICJFdmVuIGlmIHRoZSBvbmx5IHNlcnZpY2UgYW5ub3Vu Y2VkIGlzIG1ETlMsDQo+ID4gPiA+IGFuZA0KPiA+ID4gPiBtRE5TIGlzIHRoZW4gdXNlZC4uLiIg LSB3aHkgbm90ICphc3N1bWUqIHRoYXQgbUROUyBpcyBwcmVzZW50LA0KPiA+ID4gPiBhbmQgZ28g Zm9yIGl0Pw0KPiA+IA0KPiA+IEhhaGEuLi4geW91IGtub3cgdGhlIGFuc3dlciBhcyB3ZWxsIGFz IEkgZG8uwqDCoFNvbWVvbmUgd2lsbCBzYXkgdGhleQ0KPiA+IGRvbid0IHVzZSBtRE5TLCB0aGV5 IHVzZSB3aGF0IHRoZXkgY29uc2lkZXIgYmV0dGVyLsKgwqBJIGNvdWxkbid0IGJlDQo+ID4gc28N Cj4gPiBib2xkIGFzIHRvIHN1Z2dlc3QgbUROUyBhcyBhIG9uZSBzaXplIGZpdHMgYWxsIHNvbHV0 aW9uLsKgwqBUaGlzIGlzDQo+ID4gdGhlDQo+ID4gSUVURiENCj4gDQo+IFdoaWNoIGlzIGFub3Ro ZXIgcmVhc29uIG5vdCB0byBwdXQgYW5vdGhlciBzb2x1dGlvbiBmb3IgdGhlIHNhbWUNCj4gcHJv YmxlbQ0KPiBpbnRvIERMRVAsIGJlY2F1c2UgcGVvcGxlIHdpbGwgbm90IGJlIGhhcHB5IHdpdGgg aXQgYW55d2F5cy4NCg0KRmFpciBwb2ludCwgYnV0IG9uZSBkb2Vzbid0IGhhdmUgdG8gc3VwcG9y dCBpbmRpdmlkdWFsIGV4dGVuc2lvbnMsIGFzDQppdCdzIGFscmVhZHkgb3B0aW9uYWwuDQoNCj4g DQo+ID4gPiA+IEkndmUgZ29uZSBiYWNrICYgZm9ydGggb3ZlciB0aGUgbm90aW9uIG9mIHNlcnZp Y2UNCj4gPiA+ID4gYW5ub3VuY2VtZW50cy4NCj4gPiA+ID4gSSB0aGluayB3ZSdyZSBnb2luZyB0 byBnZXQgc2lnbmlmaWNhbnQgcHVzaGJhY2sgZnJvbSB0aGUgSUVURg0KPiA+ID4gPiB0aGF0IHRo ZXJlIGFyZSBhbHJlYWR5IG11bHRpcGxlIHByb3RvY29scyBmb3Igc2VydmljZQ0KPiA+ID4gPiBh bm5vdW5jZW1lbnQsIGFuZCB3ZSdyZSBqdXN0IHJlLWludmVudGluZyB0aGUgd2hlZWwgZm9yIHRo ZQ0KPiA+ID4gPiA0N3RoDQo+ID4gPiA+IHRpbWUuDQo+ID4gPiANCj4gPiA+IFRoYXQgdG9vLg0K PiA+ID4gDQo+ID4gDQo+ID4gSSBxdWl0ZSBhZ3JlZS4uLiBJJ20gZXhwZWN0aW5nIGxlZ2l0aW1h dGUgcHVzaC1iYWNrLCBJIGp1c3QgZmVlbA0KPiA+IHRoZXJlIGlzIGEgbWlzc2luZyBwaWVjZSBo ZXJlLsKgwqBUaGlzIGlzIHdoeSBteSBmaXJzdCBwYXNzIHdhcw0KPiA+IHNpbXBseQ0KPiA+IHRv IGFubm91bmNlIHR1cGxlcyBvZiBbc2VydmljZSwgYWRkcmVzcywgcG9ydF0gYW5kIG5vdCBtdWNo DQo+ID4gZWxzZS7CoMKgSXQNCj4gPiBzaG91bGQgYmUgZW5vdWdoIHRvIGJvb3RzdHJhcCB3aGF0 ZXZlciBzZXJ2aWNlIHlvdSdyZSBydW5uaW5nLg0KPiA+IEFjdHVhbGx5IHdoYXQncyBkZXNjcmli ZWQgaW4gRFNBIGlzIHZlcnkgY2xvc2UgdG8gRE5TIFNSViByZWNvcmRzLA0KPiA+IGhlbmNlIHRo ZSB0ZXh0IGZvcm0uDQo+IA0KPiBETEVQIHRyaWdnZXIgZm9yIGFuIGV4aXN0aW5nIEROUy1iYXNl ZCBzZXJ2aWNlIGRpc2NvdmVyeT8NCg0KVGhlIHdob2xlIG9mIERTQSBtaWdodCBib2lsIGRvd24g dG8gYSBzaW5nbGUgRGF0YSBJdGVtIGZvciB0aGlzLi4uDQoNCkFjdHVhbGx5IEkgbmVlZCB0byBy ZS1yZWFkIG1ETlMgdG8gY2hlY2sgaWYgaXQgd2lsbCB3b3JrIGluIHRoZSBraW5kcw0Kb2YgYWQt aG9jIHBlZXItdG8tcGVlciBtb2RlcyB3ZSdyZSBkaXNjdXNzaW5nIGhlcmUsIEkgaGF2ZSBhIHdv cnJ5IHRoYXQNCml0IGlzIGJ1aWx0IGFyb3VuZCBhIHZlcnkgaG9tZW5ldC9jbGllbnQtc2VydmVy IHZpZXcgb2YgdGhlIG5ldHdvcmsuDQoNCj4gDQo+ID4gT25lIHJlYXNvbiB3aHkgY29yZSBETEVQ IGlzIG5vdCBxdWl0ZSBnb29kIGVub3VnaCBtaWdodCBiZSB0aGF0IGENCj4gPiByZW1vdGUgcm91 dGVyIG1pZ2h0IG9ubHkgYmUgcnVubmluZyBhIGdpdmVuIHNlcnZpY2UgKHNheSBOVFApIGJvdW5k DQo+ID4gdG8gYSBsb29wYmFjayBpbnRlcmZhY2UuDQo+IA0KPiBBcmUgd2UgdGFsa2luZyBhYm91 dCBhIG5vZGUgd2l0aCByb3V0aW5nIG9yIGp1c3QgYSBsYXllci0yIGVuZHBvaW50Pw0KDQpJIGRv bid0IGFjdHVhbGx5IGNhcmUsIGFuZCBJJ20ga2VlbiBub3QgdG8gbWFrZSB0aGlzIGRpc3RpbmN0 aW9uLg0KDQo+IA0KPiA+IFRoZSBETEVQIERlc3RfVXAgbWF5IGluY2x1ZGUgdGhlIGxvb3BiYWNr DQo+ID4gYWRkcmVzcyBhcyBwYXJ0IG9mIHRoZSBJUCBhZGRyZXNzIGRhdGEgaXRlbXMgaW4gdGhl IG1lc3NhZ2UsIGJ1dA0KPiA+IGFueQ0KPiA+IHBvdGVudGlhbCBwZWVyIGlzIGdvaW5nIHRvIGhh dmUgdG8gcHJvYmUgZXZlcnkgcmVwb3J0ZWQgYWRkcmVzcw0KPiA+IHVudGlsDQo+ID4gaXQgZmlu ZHMgdGhlIG9uZSB0aGF0IHdvcmtzLCBpZiBhbnkuDQo+ID4gDQo+ID4gSSBrZWVwIHBpY2tpbmcg TlRQIGFzIHRoZSBleGFtcGxlIHNlcnZpY2UgYXMgaXQgaXMgYW4gYS1wcmlvcmkNCj4gPiBjb25m aWd1cmVkIHByb3RvY29sICh1bmxlc3MgdGhlcmUgaXMgYW4gZXhjaXRpbmcgTlRQIHBlZXIgZGlz Y292ZXJ5DQo+ID4gcHJvdG9jb2wgSSBkb24ndCBrbm93IGFib3V0KS7CoMKgRm9yIHNlcnZpY2Vz IHRoYXQgaGF2ZSBhIGRpc2NvdmVyeQ0KPiA+IHByb3RvY29sIChlLmcuIE9MU1J2MiksIERTQSBp cyBvdmVya2lsbCwgZm9yIHN0YXRpYyBJIGZlZWwgaXQncw0KPiA+IGxlc3MNCj4gPiBjbGVhciBj dXQuDQo+IA0KPiBSb3V0aW5nIG11c3QgZG8gaXRzIG93biBkaXNjb3ZlcnkgYmVjYXVzZSBpdCBo YXMgdG8gd29yayBiZWZvcmUgSXANCj4gcm91dGluZyBpcyBmaW5pc2hlZC4gOykNCg0KQWdyZWVk LCByb3V0aW5nIHNlcnZpY2VzIHdlcmUgYSBiYWQgZXhhbXBsZS4NCg0KPiANCj4gQXMgc29vbiBh cyB3ZSBoYXZlIG5vcm1hbCBjb25uZWN0aXZpdHksDQo+IA0KPiA+IFdoZXJlIGFkZGl0aW9uYWwg Y29uZmlnIGRhdGEgYmV5b25kIFtzZXJ2aWNlLGFkZHJlc3MscG9ydF0gbWlnaHQgYmUNCj4gPiB1 c2VmdWwgaXMgZm9yIHNvbWV0aGluZyBsaWtlIEJHUCBBUyBudW1iZXIsIGJ1dCB0aGUgY291bnRl ci0NCj4gPiBhcmd1bWVudA0KPiA+IGNvdWxkIGJlIHRoYXQgeW91IG9ubHkgbmVlZCB0byBhZHZl cnRpc2UgMSB0dXBsZTogW05FVENPTkYsYWRkcl0NCj4gPiA7LSkNCj4gPiANCj4gPiBJIHRoaW5r IGFueSBsYXRlciByZXZpc2lvbiB3aWxsIGhhdmUgdG8gYmUgbGliZXJhbGx5IHNwcmlua2xlZCB3 aXRoDQo+ID4gdGV4dCB0aGF0IHdhcm5zIHRoYXQgdGhpcyBleHRlbnNpb24gaXMgb25seSBmb3Ig Ym9vdHN0cmFwcGluZywgbm90DQo+ID4gZm9yIHByb3RvY29sIHBhcmFtZXRlciBuZWdvdGlhdGlv bi4NCj4gDQo+IFdoaWNoIHNvdW5kcyBsaWtlIGEgaGludCB0aGF0IHdlIHN0aWxsIGhhdmUgdG8g d29yayBvbiB0aGUgY29uY2VwdC4NCg0KT2ggeWVzLCBJIHF1aXRlIGFncmVlLiAgVGhpcyBpcyBk ZWZpbml0ZWx5IG5vdCBmaW5pc2hlZCENCg0KPiANCj4gSSBzZWUgdGhlICJuZWNlc3NhcnkiIHVz ZS1jYXNlIGZvciBhbm5vdW5jaW5nIElQcy4uLg0KPiByYWRpb3MvbW9kZW1zL25ldHdvcmtzIHRo YXQgY2FuIG5vdCBtdWx0aWNhc3QvYnJvYWRjYXN0LiBUaGV5IGFyZSBhDQo+IHBhaW4sIGJ1dCB0 aGV5IGV4aXN0Li4uIHlvdSBuZWVkIHRoZSBJUCBvZiB0aGUgb3RoZXIgc2lkZSB0byBkbw0KPiAi YXV0b21hdGljIGRpc2NvdmVyeSIuDQo+IA0KPiBJbiBmYWN0LCBOSERQIHdvcmtzIHF1aXRlIGZp bmUgb3ZlciBuZXR3b3JrcyBsaWtlIHRoaXMgaWYgeW91IGtub3cNCj4gdGhlDQo+IElQcyBvZiB0 aGUgb3RoZXIgcm91dGVyLg0KDQpZZXMsIGFuZCB0aGlzIGlzIGJlY2F1c2UgTkhEUCB3YXMgZGVz aWduZWQgZm9yIE1BTkVUcyBieSBwZW9wbGUgd2hvDQp1bmRlcnN0b29kIHRoZSBwcm9ibGVtIHNw YWNlLiAgVGhlcmUgYXJlIGhvd2V2ZXIgTGF5ZXI0KyBwcm90b2NvbHMgdGhhdA0KYXJlIHJlYWxs eSB1c2VmdWwgaW4gTUFORVRzIGJ1dCB3ZXJlIGRlc2lnbmVkIGZvciBmaXhlZCBuZXR3b3Jrcywg ZS5nLg0KTlRQLCBYTVBQIGFuZCBtb3N0IG5ldHdvcmsgb3ZlcmxheXMuICBBbnkgcHJvdG9jb2wg dGhhdCBmZWF0dXJlcyB0aGUNCmltbW9ydGFsIHBocmFzZSAiQSBUQ1AgY29ubmVjdGlvbiBpcyBt YWRlIHRvIGVhY2ggY29uZmlndXJlZCBwZWVyIiBpcyBhDQpwcmltZSBjYW5kaWRhdGUuDQoNCj4g DQo+ID4gPiA+IEhhdmluZyBzYWlkIHRoYXQsIEknbSBpbnRlcmVzdGVkIGluIGJlaW5nIGFibGUg dG8gdHJhbnNtaXQNCj4gPiA+ID4gKnNvbWUqIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYXQgRGVz dGluYXRpb24gVXAuIEZvciBleGFtcGxlLA0KPiA+ID4gPiBjb25zaWRlciBhIG1pbGl0YXJ5IGRl cGxveW1lbnQgKEkgb25seSB1c2UgaXQgYmVjYXVzZSBJJ3ZlIHNlZW4NCj4gPiA+ID4gdGhpcyBp bXBsZW1lbnRlZCwgYW5kIGNhbiBhcnRpY3VsYXRlIHRoZSBwcm9ibGVtKS4gVGhlcmUgYXJlDQo+ ID4gPiA+IHNvbWUNCj4gPiA+ID4gdmVoaWNsZXMgdGhhdCBhcmUgZXF1aXBwZWQgd2l0aCBMb1Mg bWVzaCByYWRpb3M7IGFuZCB0aGVyZSBhcmUNCj4gPiA+ID4gYWxzbyBhIGZldyBlcXVpcHBlZCB3 aXRoIHRoZSBtZXNoIHJhZGlvcyBhbmQgYSBzYXRlbGxpdGUNCj4gPiA+ID4gdGVybWluYWwvZGlz aCBmb3IgcmVhY2ggYmFjay4gSSdkIGxpa2Ugc29tZSB3YXkgZm9yIG9uZSBvZiB0aGUNCj4gPiA+ ID4gc2F0ZWxsaXRlLWVxdWlwcGVkICJyZWFjaCBiYWNrIGd1eXMiIHRvIGJlIGFibGUgdG8gY29t bXVuaWNhdGUNCj4gPiA+ID4gdmlhIERMRVAgb24gdGhlIExvUyBtZXNoIHJhZGlvIHRoYXQgIkkg aGF2ZSByZWFjaC1iYWNrDQo+ID4gPiA+IGNhcGFiaWxpdHkiLiBUbyBtZSwgdGhpcyBpbmZvcm1h dGlvbiB3b3VsZCBmb2xkIGludG8gdGhpbmdzDQo+ID4gPiA+IGxpa2UNCj4gPiA+IA0KPiA+ID4g c2VsZWN0aW9uIG9mIGEgIkRlc2lnbmF0ZWQgUm91dGVyIg0KPiA+ID4gPiBmb3IgT1NQRiwgb3Ig YW4gTVBSIGZvciBPTFNSLiBUaGlzIGlzIHNvbWV0aGluZyBvZiBhDQo+ID4gPiA+ICJjYXBhYmls aXRpZXMiIFRMViwgd2hlcmUgYSAiY2FwYWJpbGl0eSIgKGUuZy4sIHRoZSByZWFjaCBiYWNrKQ0K PiA+ID4gPiBpcyBub3QgbmVjZXNzYXJpbHkgYSBwYXJ0IG9mIHRoZSByYWRpbyBiZWluZyB1c2Vk Lg0KPiANCj4gQm90aCBPU1BGIGFuZCBPTFNSKHYyKSBhbHJlYWR5IHdvcmsgZmluZSB3aXRob3V0 IGFueSBzZXJ2aWNlDQo+IGRpc2NvdmVyeS4uLiB5b3UgY2FuIG1ha2UgdGhlbSB3b3JrIGZhc3Rl ciBieSB1c2luZyAidHJpZ2dlcmVkDQo+IEhlbGxvL1RDDQo+IG1lc3NhZ2VzIiwgZS5nLiB0cmln Z2VyZWQgYnkgRGVzdGluYXRpb24gVXAgbWVzc2FnZXMgb2YgRExFUC4NCg0KQW4gaW50ZXJlc3Rp bmcgJ3NlcnZpY2UnIG1pZ2h0IGJlIGFubm91bmNpbmcgSVBTZWMgdHVubmVsIGVuZHBvaW50DQpj YXBhYmlsaXR5LCByYXRoZXIgdGhhbiByZWx5aW5nIG9uIE5IUlAgKHdoaWNoIHJlcXVpcmVzIGEg aHViLXNwb2tlDQptb2RlbCB0byBib290c3RyYXApLiAgQSBraW5kIG9mICJJIGRvIElLRSEiIHNl cnZpY2UgYW5ub3VuY2VtZW50DQphbGxvd2luZyBETVZQTiBjb25zdHJ1Y3Rpb24gd2l0aG91dCBy ZXF1aXJpbmcgYSBodWIuICBJIGtub3cgYSBsb3Qgb2YNCm1vZGVtcyAnZG8nIHRyYW5zcG9ydCBz ZWN1cml0eSBpbiBzb21lIHVuc3BlY2lmaWVkIHdheSwgYnV0IG5vdCBhbGwgb2YNCnRoZW0sIGFu ZCBzb21ldGltZXMgYSBjb25zaXN0ZW50IHNlY3VyaXR5IHBvbGljeSBhY3Jvc3MgbXVsdGlwbGUN CmJlYXJlcnMgaXMgZGVzaXJhYmxlLiAgQXMgSSd2ZSBzYWlkIGJlZm9yZSB0aGlzIGlzIGFsbCBv cHRpb25hbC4NCg0KPiANCj4gTXkgcHJvYmxlbSB3aXRoIHRoaXMgInVzZSBETEVQIGFzIHRyYW5z cGFyZW50IHJvdXRlciB0byByb3V0ZXINCj4gY29tbXVuaWNhdGlvbiIgaXMgdGhhdCBpdCBicmVh a3MgYSBtYWpvciBkZXNpZ24gZ29hbCBvZiBETEVQIHRoYXQgSQ0KPiAod2U/KSB0b2xkIGEgbG90 IG9mIHBlb3BsZS4uLiB0aGUgYWR2YW50YWdlIG9mIERMRVAgaXMgdGhhdCBpdCBkb2VzDQo+IG5v dA0KPiBpbnRyb2R1Y2UgYWRkaXRpb25hbCBvdmVyLXRoZS1haXIgdHJhZmZpYy4gVGhlIHJhZGlv IGV4cG9ydHMNCj4gZXZlcnl0aGluZw0KPiBpdCBrbm93cyBhbmQgZXZlcnl0aGluZyBpdCBjYW4g YWxyZWFkeSBkbyBmb3IgeW91Lg0KDQpZZXMsIERMRVAgZG9lc24ndCBtYW5kYXRlIGFueSBleHRy YSBvdmVyIHRoZSBhaXIgY29tbXMsIGJ1dCBpZiB5b3UgKGFzDQphIHJhZGlvIHZlbmRvcikgYWxs b3cgRExFUCB0byBzcXVlZXplIHNvbWUgZXh0cmEgZGF0YSBpbnRvIHlvdXIgY29udHJvbA0KY2hh bm5lbCwgdGhlbiB5b3UgY2FuIHN1cHBvcnQgc29tZSByZWFsbHkgdXNlZnVsIGV4dGVuc2lvbnMu ICBJdCdzIHRoZQ0KZGlmZmVyZW5jZSBiZXR3ZWVuIE1VU1QgYW5kIE1BWS4NCg0KSSBzdXBwb3Nl IEknbSB0cnlpbmcgdG8gYWRkcmVzcyB0aGUgcHJvYmxlbSB0aGF0IHRoZSBsaW5rIGp1c3QNCmFu bm91bmNlZCBieSBETEVQIG1heSBiZSBhbiBleHRyZW1lbHkgcHJlY2lvdXMgcmVzb3VyY2UsIGFu ZCBhbnl0aGluZw0KRExFUCBjYW4gZG8gdG8gYWxsb3cgYXR0YWNoZWQgZGV2aWNlcyB0byBtYWtl IGJlc3QgdXNlIHRoZSBsaW5rIGlzIGENCmdvb2QgdGhpbmcuDQoNCj4gPiA+ID4gQW5vdGhlcg0K PiA+ID4gPiAiY2FwYWJpbGl0eSIgd291bGQgYmUgdG8gc29tZWhvdyBhbm5vdW5jZSAiSSdtIHBs dWdnZWQgaW50byBhDQo+ID4gPiA+IHJlbGlhYmxlLCAyNC83IHBvd2VyIHNvdXJjZSwgc28gYmF0 dGVyeSBjb25zdW1wdGlvbiBpc24ndCBhDQo+ID4gPiA+IHByb2JsZW0iLiBJbiBib3RoIG9mIHRo ZXNlIGNhc2VzLCB0aGV5IGVuaGFuY2UgdGhlIG5vZGUncw0KPiA+ID4gPiBhYmlsaXR5DQo+ID4g PiA+IGFuZCB3aWxsaW5nbmVzcyB0byBhY3QgYXMgYSB0cmFmZmljIHJlbGF5Lg0KPiA+IA0KPiA+ IEkgc2hhcmUgeW91ciB1c2UtY2FzZXMsIGJ1dCBJIHRoaW5rIHlvdSdyZSBpbiBkYW5nZXIgb2Yg Y29uZmxhdGluZw0KPiA+IGxvY2FsIHJhZGlvIGNhcGFiaWxpdHkgKHdoYXQgSGVubmluZyB3YXMg ZGVzaXJpbmcpIGFuZCByZW1vdGUNCj4gPiByb3V0ZXINCj4gPiBjYXBhYmlsaXR5LCBidXQgdGhh dCdzIG5vdCB0byBzYXkgSSBkb24ndCBsaWtlIHRoZSBpZGVhIG9mIGJvdGgsDQo+ID4gSSdtDQo+ ID4ganVzdCB0cnlpbmcgdG8ga2VlcCB0aGUgc2NvcGUgbWFuYWdlYWJsZS4NCj4gPiA+IENhcGFi aWxpdHkgbWlnaHQgYWxzbyBpbmNsdWRlICJuZWVkIHVuaWNhc3QgdHJhZmZpYyBmb3IgZGF0YXJh dGUNCj4gPiA+IHNlbGVjdGlvbiIuDQo+ID4gDQo+ID4gVGhhdCdzIGEgZ29vZCBjYXBhYmlsaXR5 LCBidXQgSSBjb25zaWRlciB0aGF0IG1vcmUgbG9jYWwgbm90DQo+ID4gcmVtb3RlLg0KPiA+IEkg dGhpbmsgIllvdSBuZWVkIHRvIHVzZSB0aGUgbGluayBiZWZvcmUgdGhlIENEUiBnb2VzIGFib3Zl IDAiIGlzDQo+ID4gc29tZXRoaW5nIHRoZSBsb2NhbCBtb2RlbSBzaG91bGQga25vdy4NCj4gDQo+ IFllcywgaXQgaXMuDQo+IA0KPiBBICJJIGNhbm5vdCB0byBtdWx0aWNhc3QvYnJvYWRjYXN0IiBj YXBhYmlsaXR5IGZsYWcgd291bGQgYWxzbyBiZSBhDQo+IG1ham9yIGhlbHAgZm9yIHNvbWUgcmFk aW9zLg0KDQpUaGlzIGNhbiBiZSBkb25lIGJ5IHJlamVjdGluZyBhIERlc3RpbmF0aW9uIEFubm91 bmNlIGZvciBhIG11bHRpY2FzdA0KTUFDLiAgQnV0IGl0J3Mgbm90IGluc3RhbnRseSBvYnZpb3Vz IHRoYXQgdGhpcyBjYW4gYmUgZG9uZS4NCg0KPiANCj4gPiBMZXQncyBrZWVwIHRoZSBjb252ZXJz YXRpb24gZ29pbmcsIEkgdGhpbmsgdGhlcmUgaXMgc29tZSB2YWx1ZSBpbg0KPiA+IGhlcmUgc29t ZXdoZXJlIQ0KPiANCj4gSSB0aGluayBzbyB0b28uDQoNCkRvIHlvdSBmYW5jeSBzdGFydGluZyBh ICdsb2NhbCBtb2RlbSBjYXBhYmlsaXRpZXMgYW5ub3VuY2VtZW50JyBkcmFmdD8NCg0KQ2hlZXJz LA0KDQpSaWNr From nobody Tue Sep 5 09:27:43 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F03132D79 for ; Tue, 5 Sep 2017 09:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Phl2VASshQGo for ; Tue, 5 Sep 2017 09:27:39 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2518E132D78 for ; Tue, 5 Sep 2017 09:27:39 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id m9so10356394pgd.3 for ; Tue, 05 Sep 2017 09:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:date:in-reply-to:references:mime-version :content-transfer-encoding; bh=MaZfLdot+ybJyHvXx+smoMFI0ZEKpGL+9LacSz/gjd4=; b=O87iymC4L+Jrdxcf9SGWha2ynYa1DVbk3wjOlkmDixK4QDMVhGwbBmh/Dv+p2yDu1R jxygVKk0CBzXM7WVzGVUTZvWuXmQG+58pZcnoeXf9BhLVoGcukvKF0C+o3pELNOsHrgw SV10ZAOe3k69SLyK1BoHSGE7Mhc0pIsv5kWzcmXw1sJkrnOKeDj6XWstSA61shcIyTRV guwLTvRZyqYypE0i64iwG/Rl0Ck/OXJvABH3Vn3pLuPtU5aGfUPsRob/k7se/Du9WELA Ef4Cmm4g/F/ZIhJUR4g9Lm7vKNXN3q9wQtxUfrle+hVvWz3BXk7a5o2rydos+GzlTMeK 6Wxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=MaZfLdot+ybJyHvXx+smoMFI0ZEKpGL+9LacSz/gjd4=; b=a9Kdb0sG4a+FHdG971EPMeQnFkjgW7YWotoQr822jLklhDi27B/hM2SI+8nyEA+taB lppk1jXloFcl24pKqFjmQx/fs9QNnWY++/x4TFYgUqAJUa3s9hTP+9ZgCCagnNlPgI3D mISKVSoeohYmZGS8mA02ibJ3ENRpdg9ZmPBDV4ljO5Yhl3i8i7HuOrmVcwBJt2xc/65O EztJVmsiwoVJn3Rx4T90YwVweEFI9psm3etaeMfzHMvB+wCAAc55uGVMZajIoJ9w6t40 IeIf3qkBnUUCt/2xGTkw+CItS8Yvkszhzs/6Lvkl1yE1dkZ1EcxRc/+JCekzlTaG9JFl o4ig== X-Gm-Message-State: AHPjjUiFQxhpJdEqga+Idh+fMap1ziGN6jbarigp3D4nEE2Lo8gV0K99 cIyYB8DowJe0Xw== X-Google-Smtp-Source: ADKCNb4Rq8cj7se57q8qOGjvoSPB3zKkf3TJP8zJlHR/uYii15dSBYSPL7N3jqcDnNTNVrAhHV5r8A== X-Received: by 10.99.55.25 with SMTP id e25mr4449413pga.383.1504628858459; Tue, 05 Sep 2017 09:27:38 -0700 (PDT) Received: from localhost.localdomain (c-71-198-163-21.hsd1.ca.comcast.net. [71.198.163.21]) by smtp.gmail.com with ESMTPSA id e69sm1720367pfc.79.2017.09.05.09.27.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Sep 2017 09:27:36 -0700 (PDT) Message-ID: <1504628855.2350.71.camel@gmail.com> From: Rex Buddenberg To: Rick Taylor , "henning.rogge@fkie.fraunhofer.de" , "manet@ietf.org" , "ratliffstan@gmail.com" Date: Tue, 05 Sep 2017 09:27:35 -0700 In-Reply-To: <1504603998.15735.9.camel@tropicalstormsoftware.com> References: <1500890455.2721.234.camel@tropicalstormsoftware.com> <1504171326.31980.2.camel@tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801D30BA2E9@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801D30BD277@tss-server1.home.tropicalstormsoftware.com> <275b3ace-23c6-7db1-3bb8-07dbafdde5d5@fkie.fraunhofer.de> <1504603998.15735.9.camel@tropicalstormsoftware.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [manet] New DLEP extension drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 16:27:42 -0000 Rick, Henning, et al, Interesting discussion.  My comments are not leavened with implementation experience....  But I agree with the comment that IETF has solved, or tried to solve, similar problems many times before. It appears to me that you have two problems and separation of them may be a good idea:   1.  You have a data definition and standardization problem.   2.  You have a communications problem.   Suggest a focus on each separately, with the goal that the data items can be used in several transmission means.   On Tue, 2017-09-05 at 09:33 +0000, Rick Taylor wrote: > Inline as usual... > > On Tue, 2017-09-05 at 09:51 +0200, Henning Rogge wrote: > > > > Am 04.09.2017 um 23:46 schrieb Rick Taylor: > > > > > > Ripostes inline... > > > > > > > > What is even the advantage moving "router to router" > > > > communication > > > > to DLEP? > > > The major advantage I can see is fast 'edge triggered' adjacency > > > formation.  This is one of the selling points of DLEP for Layer > > > 3, > > > so > > > why not expose Layer 4+ triggers as well.  Given I work for a > > > company > > > whose vehicles move at some speed, being able to form an > > > adjacency > > > between peer services fast is helpful.  If I have a transmission > > > window of 1 minute max, I don't want to spend the first 30 > > > seconds > > > Hello'ing with every protocol that might want to find a peer over > > > the > > > possibly restricted/flakey link. > > You could easily use the existing layer2/layer3 'edge trigger' to > > start > > a UDP (unicast?) based service discovery for the new neighbor. No > > need > > to relay the data over the radio. > Yes, I agree, you can, and I do.  My routers will use DLEP events to > kick off a proprietary service discovery protocol between peers, and > it > works beautifully.  However, it only works between my routers.  When > a > peer is a Cisco, or an OpenWRT router, or whatever, then I have to > fall > back to per-service probing. > > I also know Cisco have previously played with embedding > service/capability data in EIGRP and using that in a similar way. > > In all honesty, there is nothing big or clever about my service > discovery (it looks a lot like DSA, but with some session maintenance > messages).  When I was last reviewing the design for this it occurred > to me that it would make more sense to re-use the existing DLEP > session > to carry this extra information, hence the DSA extension draft. > > > > > > > > > > > > > > > > I can see the point of IP address propagation, especially on > > > > radios > > > > without multicast support. Without the unicast IP of the other > > > > side > > > > you cannot reach it. > > > > > > > > But for supporting services putting it into DLEP is no > > > > advantage > > > > at > > > > all... you could easily just let the routers exchange the > > > > information directly. > > > I'm not suggesting moving/wrapping the service protocol in DLEP, > > > just > > > the knowledge that it's even worth trying to begin it. > > > > > > > > > > > > > > If, as you say, "Even if the only service announced is mDNS, > > > > > and > > > > > mDNS is then used..." - why not *assume* that mDNS is > > > > > present, > > > > > and go for it? > > > Haha... you know the answer as well as I do.  Someone will say > > > they > > > don't use mDNS, they use what they consider better.  I couldn't > > > be > > > so > > > bold as to suggest mDNS as a one size fits all solution.  This is > > > the > > > IETF! > > Which is another reason not to put another solution for the same > > problem > > into DLEP, because people will not be happy with it anyways. > Fair point, but one doesn't have to support individual extensions, as > it's already optional. > > > > > > > > > > > > > > > > > > > > > > I've gone back & forth over the notion of service > > > > > announcements. > > > > > I think we're going to get significant pushback from the IETF > > > > > that there are already multiple protocols for service > > > > > announcement, and we're just re-inventing the wheel for the > > > > > 47th > > > > > time. > > > > That too. > > > > > > > I quite agree... I'm expecting legitimate push-back, I just feel > > > there is a missing piece here.  This is why my first pass was > > > simply > > > to announce tuples of [service, address, port] and not much > > > else.  It > > > should be enough to bootstrap whatever service you're running. > > > Actually what's described in DSA is very close to DNS SRV > > > records, > > > hence the text form. > > DLEP trigger for an existing DNS-based service discovery? > The whole of DSA might boil down to a single Data Item for this... > > Actually I need to re-read mDNS to check if it will work in the kinds > of ad-hoc peer-to-peer modes we're discussing here, I have a worry > that > it is built around a very homenet/client-server view of the network. > > > > > > > > > > > One reason why core DLEP is not quite good enough might be that a > > > remote router might only be running a given service (say NTP) > > > bound > > > to a loopback interface. > > Are we talking about a node with routing or just a layer-2 > > endpoint? > I don't actually care, and I'm keen not to make this distinction. > > > > > > > > > > > The DLEP Dest_Up may include the loopback > > > address as part of the IP address data items in the message, but > > > any > > > potential peer is going to have to probe every reported address > > > until > > > it finds the one that works, if any. > > > > > > I keep picking NTP as the example service as it is an a-priori > > > configured protocol (unless there is an exciting NTP peer > > > discovery > > > protocol I don't know about).  For services that have a discovery > > > protocol (e.g. OLSRv2), DSA is overkill, for static I feel it's > > > less > > > clear cut. > > Routing must do its own discovery because it has to work before Ip > > routing is finished. ;) > Agreed, routing services were a bad example. > > > > > > > As soon as we have normal connectivity, > > > > > > > > Where additional config data beyond [service,address,port] might > > > be > > > useful is for something like BGP AS number, but the counter- > > > argument > > > could be that you only need to advertise 1 tuple: [NETCONF,addr] > > > ;-) > > > > > > I think any later revision will have to be liberally sprinkled > > > with > > > text that warns that this extension is only for bootstrapping, > > > not > > > for protocol parameter negotiation. > > Which sounds like a hint that we still have to work on the concept. > Oh yes, I quite agree.  This is definitely not finished! > > > > > > > I see the "necessary" use-case for announcing IPs... > > radios/modems/networks that can not multicast/broadcast. They are a > > pain, but they exist... you need the IP of the other side to do > > "automatic discovery". > > > > In fact, NHDP works quite fine over networks like this if you know > > the > > IPs of the other router. > Yes, and this is because NHDP was designed for MANETs by people who > understood the problem space.  There are however Layer4+ protocols > that > are really useful in MANETs but were designed for fixed networks, > e.g. > NTP, XMPP and most network overlays.  Any protocol that features the > immortal phrase "A TCP connection is made to each configured peer" is > a > prime candidate. > > > > > > > > > > > > > > > > > > > > > > Having said that, I'm interested in being able to transmit > > > > > *some* additional information at Destination Up. For example, > > > > > consider a military deployment (I only use it because I've > > > > > seen > > > > > this implemented, and can articulate the problem). There are > > > > > some > > > > > vehicles that are equipped with LoS mesh radios; and there > > > > > are > > > > > also a few equipped with the mesh radios and a satellite > > > > > terminal/dish for reach back. I'd like some way for one of > > > > > the > > > > > satellite-equipped "reach back guys" to be able to > > > > > communicate > > > > > via DLEP on the LoS mesh radio that "I have reach-back > > > > > capability". To me, this information would fold into things > > > > > like > > > > selection of a "Designated Router" > > > > > > > > > > for OSPF, or an MPR for OLSR. This is something of a > > > > > "capabilities" TLV, where a "capability" (e.g., the reach > > > > > back) > > > > > is not necessarily a part of the radio being used. > > Both OSPF and OLSR(v2) already work fine without any service > > discovery... you can make them work faster by using "triggered > > Hello/TC > > messages", e.g. triggered by Destination Up messages of DLEP. > An interesting 'service' might be announcing IPSec tunnel endpoint > capability, rather than relying on NHRP (which requires a hub-spoke > model to bootstrap).  A kind of "I do IKE!" service announcement > allowing DMVPN construction without requiring a hub.  I know a lot of > modems 'do' transport security in some unspecified way, but not all > of > them, and sometimes a consistent security policy across multiple > bearers is desirable.  As I've said before this is all optional. > > > > > > > My problem with this "use DLEP as transparent router to router > > communication" is that it breaks a major design goal of DLEP that I > > (we?) told a lot of people... the advantage of DLEP is that it does > > not > > introduce additional over-the-air traffic. The radio exports > > everything > > it knows and everything it can already do for you. > Yes, DLEP doesn't mandate any extra over the air comms, but if you > (as > a radio vendor) allow DLEP to squeeze some extra data into your > control > channel, then you can support some really useful extensions.  It's > the > difference between MUST and MAY. > > I suppose I'm trying to address the problem that the link just > announced by DLEP may be an extremely precious resource, and anything > DLEP can do to allow attached devices to make best use the link is a > good thing. > > > > > > > > > > > > > > > > > > > > Another > > > > > "capability" would be to somehow announce "I'm plugged into a > > > > > reliable, 24/7 power source, so battery consumption isn't a > > > > > problem". In both of these cases, they enhance the node's > > > > > ability > > > > > and willingness to act as a traffic relay. > > > I share your use-cases, but I think you're in danger of > > > conflating > > > local radio capability (what Henning was desiring) and remote > > > router > > > capability, but that's not to say I don't like the idea of both, > > > I'm > > > just trying to keep the scope manageable. > > > > > > > > Capability might also include "need unicast traffic for > > > > datarate > > > > selection". > > > That's a good capability, but I consider that more local not > > > remote. > > > I think "You need to use the link before the CDR goes above 0" is > > > something the local modem should know. > > Yes, it is. > > > > A "I cannot to multicast/broadcast" capability flag would also be a > > major help for some radios. > This can be done by rejecting a Destination Announce for a multicast > MAC.  But it's not instantly obvious that this can be done. > > > > > > > > > > > Let's keep the conversation going, I think there is some value in > > > here somewhere! > > I think so too. > Do you fancy starting a 'local modem capabilities announcement' > draft? > > Cheers, > > Rick > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Sep 5 09:54:15 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E959132D98 for ; Tue, 5 Sep 2017 09:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IWft2cBvJhbK for ; Tue, 5 Sep 2017 09:54:11 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26A0E132D8B for ; Tue, 5 Sep 2017 09:54:11 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id i200so18774344ioa.2 for ; Tue, 05 Sep 2017 09:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Nh2YMvidrzPEFwtD9No0d6u04yAFLvV9XNKK/xbGjQg=; b=CAYMD7Lma6i2PgM93RZkdlk7j7RdDlZNXmm1lxtb+i4n1S1OiFHrMpPfLWeKUv1+6x /OWB3elal7wPuobHm8CnzW62BSUZ69kXtOT/mTPvAjzp/mlrAWfHztgCWLb0uUM7d/G9 Bl9ng9VysKHlIrCaIqj/9DyFzdXXhRsa9lRuotMNhqJe5ouSKcDXWDS1s6LHg6oqlv7G k3LIVkqoubw8bQnAaUi9E+dVzohEHDpX7W0NDXgaFjXhZAAzN4lSwKvCtDtPns2pFkAe t2s2hL946sQI3ODeTRAPmtG8fS1jfJrgVhj1KXDIovLzgTEGymgLhMTfPmMu0BPfpZT7 hTEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nh2YMvidrzPEFwtD9No0d6u04yAFLvV9XNKK/xbGjQg=; b=XMLoG8kX7w2ntN/ym62nvN+RC3OAz5X4O4GX7M9p8w8O5/i7bgV/6BkLJbtYH1JmoQ YmZb5BfLbOHp0qYqUZWubwNJ1bbEa0CpBdYUrAZ9eqdWv3dnUb+v85oaELNT1aqa9YO6 f1lJBA1yzF3T9AsKDZN1cAtZukFYg8KlsPXG/6Z9y9CgPS6njYoTAwwFxw3fTJHrR/fx 7/dhskiXYH8y+Ank1qar1vhU9+4Yd4ZiVxw2vkDhsa0aGey5OeImsr8FaMy+seXtIwn5 HSszzw13Gh8388V/F2S+aDCJuV+ttV+uyMe0EHtWPw57cyIyC7ipJhcP1EQ4PGm2WQYo KymA== X-Gm-Message-State: AHPjjUjVyTu3yXan5doBO0lNJpfqCiKUDv9sQMAbXacMOJnXHwNTgQn1 Qsp4wvaClhenqba7YNChz7Odko2YxQ== X-Google-Smtp-Source: ADKCNb731Ik1I6LfPW3vzDuDabO9iB09e3XNnhIP/HMV72aexkoizlMiFpUECxzfyDd8w72tnuo/wYH16zH8WFxRLQ0= X-Received: by 10.107.104.4 with SMTP id d4mr5291135ioc.72.1504630450311; Tue, 05 Sep 2017 09:54:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.124.138 with HTTP; Tue, 5 Sep 2017 09:54:09 -0700 (PDT) In-Reply-To: <1504603998.15735.9.camel@tropicalstormsoftware.com> References: <1500890455.2721.234.camel@tropicalstormsoftware.com> <1504171326.31980.2.camel@tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801D30BA2E9@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801D30BD277@tss-server1.home.tropicalstormsoftware.com> <275b3ace-23c6-7db1-3bb8-07dbafdde5d5@fkie.fraunhofer.de> <1504603998.15735.9.camel@tropicalstormsoftware.com> From: Stan Ratliff Date: Tue, 5 Sep 2017 12:54:09 -0400 Message-ID: To: Rick Taylor Cc: "henning.rogge@fkie.fraunhofer.de" , "manet@ietf.org" Content-Type: multipart/alternative; boundary="089e0825fdec8266020558741340" Archived-At: Subject: Re: [manet] New DLEP extension drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 16:54:14 -0000 --089e0825fdec8266020558741340 Content-Type: text/plain; charset="UTF-8" On Tue, Sep 5, 2017 at 5:33 AM, Rick Taylor wrote: > Inline as usual... > > On Tue, 2017-09-05 at 09:51 +0200, Henning Rogge wrote: > > Am 04.09.2017 um 23:46 schrieb Rick Taylor: > > > Ripostes inline... > > > > What is even the advantage moving "router to router" > > > > communication > > > > to DLEP? > > > > > > The major advantage I can see is fast 'edge triggered' adjacency > > > formation. This is one of the selling points of DLEP for Layer 3, > > > so > > > why not expose Layer 4+ triggers as well. Given I work for a > > > company > > > whose vehicles move at some speed, being able to form an adjacency > > > between peer services fast is helpful. If I have a transmission > > > window of 1 minute max, I don't want to spend the first 30 seconds > > > Hello'ing with every protocol that might want to find a peer over > > > the > > > possibly restricted/flakey link. > > > > You could easily use the existing layer2/layer3 'edge trigger' to > > start > > a UDP (unicast?) based service discovery for the new neighbor. No > > need > > to relay the data over the radio. > > Yes, I agree, you can, and I do. My routers will use DLEP events to > kick off a proprietary service discovery protocol between peers, and it > works beautifully. However, it only works between my routers. When a > peer is a Cisco, or an OpenWRT router, or whatever, then I have to fall > back to per-service probing. > > I also know Cisco have previously played with embedding > service/capability data in EIGRP and using that in a similar way. > > In all honesty, there is nothing big or clever about my service > discovery (it looks a lot like DSA, but with some session maintenance > messages). When I was last reviewing the design for this it occurred > to me that it would make more sense to re-use the existing DLEP session > to carry this extra information, hence the DSA extension draft. > This looks like more of an implementation problem to me - one that doesn't actually require an interoperability spec. There's more than 1 way to leverage existing hooks (up to and including using some of the "private use" TLVs) to transmit the information you're looking for. Right now, from your description, I get the mental image of an Airbus A380 arbitrarily connecting up to..... WiFi at Starbucks? One of Henning's roof-top nodes? And then scrounging around for services. It also seems like there's a potential for a hacker exploit - if some bad actor gets connected to one of these radios, it would get a list of services available, which leads to the attacker knowing how to disrupt the service. > > > > > > > I can see the point of IP address propagation, especially on > > > > radios > > > > without multicast support. Without the unicast IP of the other > > > > side > > > > you cannot reach it. > > > > > > > > But for supporting services putting it into DLEP is no advantage > > > > at > > > > all... you could easily just let the routers exchange the > > > > information directly. > > > > > > I'm not suggesting moving/wrapping the service protocol in DLEP, > > > just > > > the knowledge that it's even worth trying to begin it. > > > > > If, as you say, "Even if the only service announced is mDNS, > > > > > and > > > > > mDNS is then used..." - why not *assume* that mDNS is present, > > > > > and go for it? > > > > > > Haha... you know the answer as well as I do. Someone will say they > > > don't use mDNS, they use what they consider better. I couldn't be > > > so > > > bold as to suggest mDNS as a one size fits all solution. This is > > > the > > > IETF! > > > > Which is another reason not to put another solution for the same > > problem > > into DLEP, because people will not be happy with it anyways. > > Fair point, but one doesn't have to support individual extensions, as > it's already optional. > > > > > > > > I've gone back & forth over the notion of service > > > > > announcements. > > > > > I think we're going to get significant pushback from the IETF > > > > > that there are already multiple protocols for service > > > > > announcement, and we're just re-inventing the wheel for the > > > > > 47th > > > > > time. > > > > > > > > That too. > > > > > > > > > > I quite agree... I'm expecting legitimate push-back, I just feel > > > there is a missing piece here. This is why my first pass was > > > simply > > > to announce tuples of [service, address, port] and not much > > > else. It > > > should be enough to bootstrap whatever service you're running. > > > Actually what's described in DSA is very close to DNS SRV records, > > > hence the text form. > > > > DLEP trigger for an existing DNS-based service discovery? > > The whole of DSA might boil down to a single Data Item for this... > > Actually I need to re-read mDNS to check if it will work in the kinds > of ad-hoc peer-to-peer modes we're discussing here, I have a worry that > it is built around a very homenet/client-server view of the network. > > > > > > One reason why core DLEP is not quite good enough might be that a > > > remote router might only be running a given service (say NTP) bound > > > to a loopback interface. > > > > Are we talking about a node with routing or just a layer-2 endpoint? > > I don't actually care, and I'm keen not to make this distinction. > > > > > > The DLEP Dest_Up may include the loopback > > > address as part of the IP address data items in the message, but > > > any > > > potential peer is going to have to probe every reported address > > > until > > > it finds the one that works, if any. > > > > > > I keep picking NTP as the example service as it is an a-priori > > > configured protocol (unless there is an exciting NTP peer discovery > > > protocol I don't know about). For services that have a discovery > > > protocol (e.g. OLSRv2), DSA is overkill, for static I feel it's > > > less > > > clear cut. > > > > Routing must do its own discovery because it has to work before Ip > > routing is finished. ;) > > Agreed, routing services were a bad example. > > > > > As soon as we have normal connectivity, > > > > > Where additional config data beyond [service,address,port] might be > > > useful is for something like BGP AS number, but the counter- > > > argument > > > could be that you only need to advertise 1 tuple: [NETCONF,addr] > > > ;-) > > > > > > I think any later revision will have to be liberally sprinkled with > > > text that warns that this extension is only for bootstrapping, not > > > for protocol parameter negotiation. > > > > Which sounds like a hint that we still have to work on the concept. > > Oh yes, I quite agree. This is definitely not finished! > > > > > I see the "necessary" use-case for announcing IPs... > > radios/modems/networks that can not multicast/broadcast. They are a > > pain, but they exist... you need the IP of the other side to do > > "automatic discovery". > > > > In fact, NHDP works quite fine over networks like this if you know > > the > > IPs of the other router. > > Yes, and this is because NHDP was designed for MANETs by people who > understood the problem space. There are however Layer4+ protocols that > are really useful in MANETs but were designed for fixed networks, e.g. > NTP, XMPP and most network overlays. Any protocol that features the > immortal phrase "A TCP connection is made to each configured peer" is a > prime candidate. > > > > > > > > Having said that, I'm interested in being able to transmit > > > > > *some* additional information at Destination Up. For example, > > > > > consider a military deployment (I only use it because I've seen > > > > > this implemented, and can articulate the problem). There are > > > > > some > > > > > vehicles that are equipped with LoS mesh radios; and there are > > > > > also a few equipped with the mesh radios and a satellite > > > > > terminal/dish for reach back. I'd like some way for one of the > > > > > satellite-equipped "reach back guys" to be able to communicate > > > > > via DLEP on the LoS mesh radio that "I have reach-back > > > > > capability". To me, this information would fold into things > > > > > like > > > > > > > > selection of a "Designated Router" > > > > > for OSPF, or an MPR for OLSR. This is something of a > > > > > "capabilities" TLV, where a "capability" (e.g., the reach back) > > > > > is not necessarily a part of the radio being used. > > > > Both OSPF and OLSR(v2) already work fine without any service > > discovery... you can make them work faster by using "triggered > > Hello/TC > > messages", e.g. triggered by Destination Up messages of DLEP. > > An interesting 'service' might be announcing IPSec tunnel endpoint > capability, rather than relying on NHRP (which requires a hub-spoke > model to bootstrap). A kind of "I do IKE!" service announcement > allowing DMVPN construction without requiring a hub. I know a lot of > modems 'do' transport security in some unspecified way, but not all of > them, and sometimes a consistent security policy across multiple > bearers is desirable. As I've said before this is all optional. > I still want to push for some of the characteristics I listed earlier. And to avoid confusion, I'm looking at them as remote characteristics. If I have a vehicle with an LoS radio, and I connect to another vehicle that has LoS and Satcom, I want to know sooner rather than later. I also want to know if my new connection partner is actually a "base station" (with good uninterruptible power), because that could influence my routing decisions. I also like the notion of "I do IKE!"... I'm not completely sure, but I don't think there are any IPSec/IKE discovery protocols. > > > > > My problem with this "use DLEP as transparent router to router > > communication" is that it breaks a major design goal of DLEP that I > > (we?) told a lot of people... the advantage of DLEP is that it does > > not > > introduce additional over-the-air traffic. The radio exports > > everything > > it knows and everything it can already do for you. > > Yes, DLEP doesn't mandate any extra over the air comms, but if you (as > a radio vendor) allow DLEP to squeeze some extra data into your control > channel, then you can support some really useful extensions. It's the > difference between MUST and MAY. > +1 with Rick here. Yes, I've told people that no OTA traffic is *specified*. And for the base DLEP, that will always be the case. But again, if a radio vendor wants to exploit the Layer 3 addressing, then additional OTA is required. If a vendor wanted to support this extension, more OTA transmission is required. Since the extensions are (more or less) a-la-carte, then you pick & choose as you see fit. > > I suppose I'm trying to address the problem that the link just > announced by DLEP may be an extremely precious resource, and anything > DLEP can do to allow attached devices to make best use the link is a > good thing. > > > > > > Another > > > > > "capability" would be to somehow announce "I'm plugged into a > > > > > reliable, 24/7 power source, so battery consumption isn't a > > > > > problem". In both of these cases, they enhance the node's > > > > > ability > > > > > and willingness to act as a traffic relay. > > > > > > I share your use-cases, but I think you're in danger of conflating > > > local radio capability (what Henning was desiring) and remote > > > router > > > capability, but that's not to say I don't like the idea of both, > > > I'm > > > just trying to keep the scope manageable. > > > > Capability might also include "need unicast traffic for datarate > > > > selection". > > > > > > That's a good capability, but I consider that more local not > > > remote. > > > I think "You need to use the link before the CDR goes above 0" is > > > something the local modem should know. > > > > Yes, it is. > > > > A "I cannot to multicast/broadcast" capability flag would also be a > > major help for some radios. > > This can be done by rejecting a Destination Announce for a multicast > MAC. But it's not instantly obvious that this can be done. > > > > > > Let's keep the conversation going, I think there is some value in > > > here somewhere! > > > > I think so too. > > Do you fancy starting a 'local modem capabilities announcement' draft? > I'd prefer (and am volunteering to help) making it a "capabilities draft" - one that encompasses both 'local' and 'remote' capabilities. I think the scope is manageable, Regards, Stan --089e0825fdec8266020558741340 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 5, 2017 at 5:33 AM, Rick Taylor <rick@tropica= lstormsoftware.com> wrote:
Inline as usual...

On Tue, 2017-09-05 at 09:51 +0200, Henning Rogge wrote:
> Am 04.09.2017 um 23:46 schrieb Rick Taylor:
> > Ripostes inline...
> > > What is even the advantage moving "router to router&quo= t;
> > > communication
> > > to DLEP?
> >
> > The major advantage I can see is fast 'edge triggered' ad= jacency
> > formation.=C2=A0=C2=A0This is one of the selling points of DLEP f= or Layer 3,
> > so
> > why not expose Layer 4+ triggers as well.=C2=A0=C2=A0Given I work= for a
> > company
> > whose vehicles move at some speed, being able to form an adjacenc= y
> > between peer services fast is helpful.=C2=A0=C2=A0If I have a tra= nsmission
> > window of 1 minute max, I don't want to spend the first 30 se= conds
> > Hello'ing with every protocol that might want to find a peer = over
> > the
> > possibly restricted/flakey link.
>
> You could easily use the existing layer2/layer3 'edge trigger'= to
> start
> a UDP (unicast?) based service discovery for the new neighbor. No
> need
> to relay the data over the radio.

Yes, I agree, you can, and I do.=C2=A0 My routers will use DLEP events to kick off a proprietary service discovery protocol between peers, and it
works beautifully.=C2=A0 However, it only works between my routers.=C2=A0 W= hen a
peer is a Cisco, or an OpenWRT router, or whatever, then I have to fall
back to per-service probing.

I also know Cisco have previously played with embedding
service/capability data in EIGRP and using that in a similar way.

In all honesty, there is nothing big or clever about my service
discovery (it looks a lot like DSA, but with some session maintenance
messages).=C2=A0 When I was last reviewing the design for this it occurred<= br> to me that it would make more sense to re-use the existing DLEP session
to carry this extra information, hence the DSA extension draft.

This looks like more of an implementation problem = to me - one that doesn't actually require an interoperability spec. The= re's more than 1 way to leverage existing hooks (up to and including us= ing some of the "private use" TLVs) to transmit the information y= ou're looking for.=C2=A0

Right now, from your = description, I get the mental image of an Airbus A380 arbitrarily connectin= g up to..... WiFi at Starbucks? One of Henning's roof-top nodes? And th= en scrounging around for services. It also seems like there's a potenti= al for a hacker exploit - if some bad actor gets connected to one of these = radios, it would get a list of services available, which leads to the attac= ker knowing how to disrupt the service.=C2=A0
=C2=A0

>
> > > I can see the point of IP address propagation, especially on=
> > > radios
> > > without multicast support. Without the unicast IP of the oth= er
> > > side
> > > you cannot reach it.
> > >
> > > But for supporting services putting it into DLEP is no advan= tage
> > > at
> > > all... you could easily just let the routers exchange the > > > information directly.
> >
> > I'm not suggesting moving/wrapping the service protocol in DL= EP,
> > just
> > the knowledge that it's even worth trying to begin it.
> > > > If, as you say, "Even if the only service announce= d is mDNS,
> > > > and
> > > > mDNS is then used..." - why not *assume* that mDNS= is present,
> > > > and go for it?
> >
> > Haha... you know the answer as well as I do.=C2=A0=C2=A0Someone w= ill say they
> > don't use mDNS, they use what they consider better.=C2=A0=C2= =A0I couldn't be
> > so
> > bold as to suggest mDNS as a one size fits all solution.=C2=A0=C2= =A0This is
> > the
> > IETF!
>
> Which is another reason not to put another solution for the same
> problem
> into DLEP, because people will not be happy with it anyways.

Fair point, but one doesn't have to support individual extensions, as it's already optional.

>
> > > > I've gone back & forth over the notion of servi= ce
> > > > announcements.
> > > > I think we're going to get significant pushback fro= m the IETF
> > > > that there are already multiple protocols for service > > > > announcement, and we're just re-inventing the wheel= for the
> > > > 47th
> > > > time.
> > >
> > > That too.
> > >
> >
> > I quite agree... I'm expecting legitimate push-back, I just f= eel
> > there is a missing piece here.=C2=A0=C2=A0This is why my first pa= ss was
> > simply
> > to announce tuples of [service, address, port] and not much
> > else.=C2=A0=C2=A0It
> > should be enough to bootstrap whatever service you're running= .
> > Actually what's described in DSA is very close to DNS SRV rec= ords,
> > hence the text form.
>
> DLEP trigger for an existing DNS-based service discovery?

The whole of DSA might boil down to a single Data Item for this...

Actually I need to re-read mDNS to check if it will work in the kinds
of ad-hoc peer-to-peer modes we're discussing here, I have a worry that=
it is built around a very homenet/client-server view of the network.

>
> > One reason why core DLEP is not quite good enough might be that a=
> > remote router might only be running a given service (say NTP) bou= nd
> > to a loopback interface.
>
> Are we talking about a node with routing or just a layer-2 endpoint?
I don't actually care, and I'm keen not to make this distinction.
>
> > The DLEP Dest_Up may include the loopback
> > address as part of the IP address data items in the message, but<= br> > > any
> > potential peer is going to have to probe every reported address > > until
> > it finds the one that works, if any.
> >
> > I keep picking NTP as the example service as it is an a-priori > > configured protocol (unless there is an exciting NTP peer discove= ry
> > protocol I don't know about).=C2=A0=C2=A0For services that ha= ve a discovery
> > protocol (e.g. OLSRv2), DSA is overkill, for static I feel it'= ;s
> > less
> > clear cut.
>
> Routing must do its own discovery because it has to work before Ip
> routing is finished. ;)

Agreed, routing services were a bad example.

>
> As soon as we have normal connectivity,
>
> > Where additional config data beyond [service,address,port] might = be
> > useful is for something like BGP AS number, but the counter-
> > argument
> > could be that you only need to advertise 1 tuple: [NETCONF,addr]<= br> > > ;-)
> >
> > I think any later revision will have to be liberally sprinkled wi= th
> > text that warns that this extension is only for bootstrapping, no= t
> > for protocol parameter negotiation.
>
> Which sounds like a hint that we still have to work on the concept.
Oh yes, I quite agree.=C2=A0 This is definitely not finished!

>
> I see the "necessary" use-case for announcing IPs...
> radios/modems/networks that can not multicast/broadcast. They are a > pain, but they exist... you need the IP of the other side to do
> "automatic discovery".
>
> In fact, NHDP works quite fine over networks like this if you know
> the
> IPs of the other router.

Yes, and this is because NHDP was designed for MANETs by people who
understood the problem space.=C2=A0 There are however Layer4+ protocols tha= t
are really useful in MANETs but were designed for fixed networks, e.g.
NTP, XMPP and most network overlays.=C2=A0 Any protocol that features the immortal phrase "A TCP connection is made to each configured peer"= ; is a
prime candidate.

>
> > > > Having said that, I'm interested in being able to t= ransmit
> > > > *some* additional information at Destination Up. For ex= ample,
> > > > consider a military deployment (I only use it because I= 've seen
> > > > this implemented, and can articulate the problem). Ther= e are
> > > > some
> > > > vehicles that are equipped with LoS mesh radios; and th= ere are
> > > > also a few equipped with the mesh radios and a satellit= e
> > > > terminal/dish for reach back. I'd like some way for= one of the
> > > > satellite-equipped "reach back guys" to be ab= le to communicate
> > > > via DLEP on the LoS mesh radio that "I have reach-= back
> > > > capability". To me, this information would fold in= to things
> > > > like
> > >
> > > selection of a "Designated Router"
> > > > for OSPF, or an MPR for OLSR. This is something of a > > > > "capabilities" TLV, where a "capability&= quot; (e.g., the reach back)
> > > > is not necessarily a part of the radio being used.
>
> Both OSPF and OLSR(v2) already work fine without any service
> discovery... you can make them work faster by using "triggered > Hello/TC
> messages", e.g. triggered by Destination Up messages of DLEP.

An interesting 'service' might be announcing IPSec tunnel endpoint<= br> capability, rather than relying on NHRP (which requires a hub-spoke
model to bootstrap).=C2=A0 A kind of "I do IKE!" service announce= ment
allowing DMVPN construction without requiring a hub.=C2=A0 I know a lot of<= br> modems 'do' transport security in some unspecified way, but not all= of
them, and sometimes a consistent security policy across multiple
bearers is desirable.=C2=A0 As I've said before this is all optional.

I still want to push for some of the cha= racteristics I listed earlier. And to avoid confusion, I'm looking at t= hem as remote characteristics. If I have a vehicle with an LoS radio, and I= connect to another vehicle that has LoS and Satcom, I want to know sooner = rather than later. I also want to know if my new connection partner is actu= ally a "base station" (with good uninterruptible power), because = that could influence my routing decisions. I also like the notion of "= I do IKE!"... I'm not completely sure, but I don't think there= are any IPSec/IKE discovery protocols.=C2=A0
=C2=A0

>
> My problem with this "use DLEP as transparent router to router > communication" is that it breaks a major design goal of DLEP that= I
> (we?) told a lot of people... the advantage of DLEP is that it does > not
> introduce additional over-the-air traffic. The radio exports
> everything
> it knows and everything it can already do for you.

Yes, DLEP doesn't mandate any extra over the air comms, but if you (as<= br> a radio vendor) allow DLEP to squeeze some extra data into your control
channel, then you can support some really useful extensions.=C2=A0 It's= the
difference between MUST and MAY.

+1 wit= h Rick here. Yes, I've told people that no OTA traffic is *specified*. = And for the base DLEP, that will always be the case. But again, if a radio = vendor wants to exploit the Layer 3 addressing, then additional OTA is requ= ired. If a vendor wanted to support this extension, more OTA transmission i= s required. Since the extensions are (more or less) a-la-carte, then you pi= ck & choose as you see fit.=C2=A0
=C2=A0

I suppose I'm trying to address the problem that the link just
announced by DLEP may be an extremely precious resource, and anything
DLEP can do to allow attached devices to make best use the link is a
good thing.

> > > > Another
> > > > "capability" would be to somehow announce &qu= ot;I'm plugged into a
> > > > reliable, 24/7 power source, so battery consumption isn= 't a
> > > > problem". In both of these cases, they enhance the= node's
> > > > ability
> > > > and willingness to act as a traffic relay.
> >
> > I share your use-cases, but I think you're in danger of confl= ating
> > local radio capability (what Henning was desiring) and remote
> > router
> > capability, but that's not to say I don't like the idea o= f both,
> > I'm
> > just trying to keep the scope manageable.
> > > Capability might also include "need unicast traffic for= datarate
> > > selection".
> >
> > That's a good capability, but I consider that more local not<= br> > > remote.
> > I think "You need to use the link before the CDR goes above = 0" is
> > something the local modem should know.
>
> Yes, it is.
>
> A "I cannot to multicast/broadcast" capability flag would al= so be a
> major help for some radios.

This can be done by rejecting a Destination Announce for a multicast
MAC.=C2=A0 But it's not instantly obvious that this can be done.

>
> > Let's keep the conversation going, I think there is some valu= e in
> > here somewhere!
>
> I think so too.

Do you fancy starting a 'local modem capabilities announcement' dra= ft?

I'd prefer (and am volunteering= to help) making it a "capabilities draft" - one that encompasses= both 'local' and 'remote' capabilities. I think the scope = is manageable,=C2=A0

Regards,
Stan
=

--089e0825fdec8266020558741340-- From nobody Thu Sep 7 03:58:04 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A2F132703 for ; Thu, 7 Sep 2017 03:58:03 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam_report: ...that system for details.\n \n Content previ[...] X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 wFokyTfImX4w for ; Thu, 7 Sep 2017 03:58:01 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0438C126D0C for ; Thu, 7 Sep 2017 03:58:01 -0700 (PDT) Received: from rufsun5.fkie.fraunhofer.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1dpuVS-0003gk-22; Thu, 07 Sep 2017 12:57:58 +0200 Received: from srv-mail-01.fkie.fraunhofer.de ([128.7.11.16] helo=srv-mail-01.gaia.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dpuVR-0000BN-V8; Thu, 07 Sep 2017 12:57:57 +0200 Received: from [10.71.67.24] (128.7.89.212) by srv-mail-01.gaia.fkie.fraunhofer.de (128.7.11.16) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 7 Sep 2017 12:57:55 +0200 To: From: Henning Rogge Message-ID: Date: Thu, 7 Sep 2017 12:57:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [128.7.89.212] X-ClientProxiedBy: srv-mail-02.gaia.fkie.fraunhofer.de (128.7.11.17) To srv-mail-01.gaia.fkie.fraunhofer.de (128.7.11.16) X-Virus-Scanned: yes (ClamAV 0.99.2/23787/Thu Sep 7 10:35:05 2017) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 7099e5c0d5ab5062723c81c460487660 X-Spam_score: -1.0 X-Spam_score_int: -9 X-Spam_bar: - X-Spam_report: Spam detection software, running on the system "mailguard.fkie.fraunhofer.de", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: I had some time to look at draft-dlep-lid and there is one thing I am wondering about. I wonder if leaving out the MAC TLV is a bit too tough on many DLEP implementations, we are talking about the "primary key" for the neighbors. [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SHORTCIRCUIT Not all rules were run, due to a shortcircuited rule -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-ASN: Archived-At: Subject: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 10:58:03 -0000 I had some time to look at draft-dlep-lid and there is one thing I am wondering about. I wonder if leaving out the MAC TLV is a bit too tough on many DLEP implementations, we are talking about the "primary key" for the neighbors. Whats about adding a "IP hops" TLV instead, which tells the router how many IP hops a neighbor is away? Default value would be zero (briding distance), but routing radios would report something like 2 (two routers in between, one on each radio). This value might also be useful later for "multihop routing" radios. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Zanderstrasse 5, 53177 Bonn, Germany Telefon +49 228 50212-469 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From nobody Thu Sep 7 15:55:09 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B76813207A for ; Thu, 7 Sep 2017 15:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ua691lnrmMnX for ; Thu, 7 Sep 2017 15:55:05 -0700 (PDT) Received: from ch3vs02.rockwellcollins.com (ch3vs02.rockwellcollins.com [205.175.226.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAA6F12895E for ; Thu, 7 Sep 2017 15:55:04 -0700 (PDT) X-RC-All-From: , 205.175.226.20, No hostname, james.a.stevens@rockwellcollins.com, "James A. (Jim) Stevens" , , X-RC-Attachments: , , X-RC-RemoteIP: 205.175.226.20 X-RC-RemoteHost: No hostname X-RC-IP-Hostname: ch3ip02.rockwellcollins.com X-RC-IP-MID: 68327474 X-RC-IP-Group: GOOGLE_RELAYED X-RC-IP-Policy: $GOOGLE_RELAYED X-RC-IP-SBRS: None Received: from unknown (HELO mail-wm0-f72.google.com) ([205.175.226.20]) by ch3vs02.rockwellcollins.com with ESMTP/TLS/AES128-GCM-SHA256; 07 Sep 2017 17:55:04 -0500 Received: by mail-wm0-f72.google.com with SMTP id f4so573442wmh.7 for ; Thu, 07 Sep 2017 15:55:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Nk2CuRZwXxPnFkEwEebnl2FFB4S3ip7F52cj7DkiXAU=; b=o7xTQpiGV6mm5dO1efpmEvohykjMuyAZjxd0pDCwsGTlh5vSHayDJGiPmduVndy/Me pfycu7ezY5GFYPa6JybT4ySxyzBNc5NQ0+IdISy7MAa7LMjy+nC+hgVys3nw1geEQux9 AjqhF/wjjgwiyTnOB5yWEUYzDtLZCEOm/udVdK4puPd/7M7Djfdw0JmT88hAiIs99LUT f4xEQmQQYkcGJLLcxgWQTM2w1zMA5Hr9PMAvbXOZuvwjbddERYFngd8TkXHOZ1f4/HvD 8dCF9lYna/1tCvYyh+VTzoRUVXSpQRyf3RSAyixmjTFrYDv5I+q2MWCtM1bKS9O75W57 k59g== X-Gm-Message-State: AHPjjUjBAwmnoQVuhvZ2VW9vy7q+zDUKZ/D97RRo9YS7XN05fMkFo1PA lyCeDHOyEJer26RWQqtK5SAfnJ9Xsyvdu7t1uOBLG3CX/X93xHFW0qComznSpksYpzUGhn++AqY mFSC95xvccNQ8GJ/9dYzaMdilgxAAFJ3hWYDtTG30 X-Received: by 10.28.58.2 with SMTP id h2mr160491wma.129.1504824901730; Thu, 07 Sep 2017 15:55:01 -0700 (PDT) X-Google-Smtp-Source: AOwi7QAgYYpsirw6jqhTVExObo8k00WZB0aq2YqqtvK9bjOQiLoQJt1mMpO/RSaGe9oWRHvzUbutBrY4z5ULeEqpPHk= X-Received: by 10.28.58.2 with SMTP id h2mr160490wma.129.1504824901511; Thu, 07 Sep 2017 15:55:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.142.3 with HTTP; Thu, 7 Sep 2017 15:55:01 -0700 (PDT) In-Reply-To: References: From: "James A. (Jim) Stevens" Date: Thu, 7 Sep 2017 17:55:01 -0500 Message-ID: To: manet@ietf.org Content-Type: multipart/alternative; boundary="001a1148f6d4b43b170558a15944" Archived-At: Subject: Re: [manet] manet Digest, Vol 160, Issue 6 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 22:55:07 -0000 --001a1148f6d4b43b170558a15944 Content-Type: text/plain; charset="UTF-8" what about radio routing hops below IP, e.g. for a mesh network below IP? This would tell the router how many radio hops (as contrasted to IP hops) away a neighbor is. Jim Stevens On Thu, Sep 7, 2017 at 2:00 PM, wrote: > Send manet mailing list submissions to > manet@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/manet > or, via email, send a message with subject or body 'help' to > manet-request@ietf.org > > You can reach the person managing the list at > manet-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of manet digest..." > > > Today's Topics: > > 1. Thoughts on draft-dlep-lid (Henning Rogge) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 7 Sep 2017 12:57:53 +0200 > From: Henning Rogge > To: > Subject: [manet] Thoughts on draft-dlep-lid > Message-ID: > Content-Type: text/plain; charset="utf-8"; format=flowed > > I had some time to look at draft-dlep-lid and there is one thing I am > wondering about. > > I wonder if leaving out the MAC TLV is a bit too tough on many DLEP > implementations, we are talking about the "primary key" for the neighbors. > > Whats about adding a "IP hops" TLV instead, which tells the router how > many IP hops a neighbor is away? > > Default value would be zero (briding distance), but routing radios would > report something like 2 (two routers in between, one on each radio). > > This value might also be useful later for "multihop routing" radios. > > Henning Rogge > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f?r > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Zanderstrasse 5, 53177 Bonn, Germany > Telefon +49 228 50212-469 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > ------------------------------ > > End of manet Digest, Vol 160, Issue 6 > ************************************* > --001a1148f6d4b43b170558a15944 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
wha= t about radio routing hops below IP, e.g. for a mesh network below IP?

This would tell the router ho= w many radio hops (as contrasted to IP hops) away a neighbor is.

Jim Stevens

<= br>
On Thu, Sep 7, 2017 at 2:00 PM, <manet= -request@ietf.org> wrote:
S= end manet mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 manet@ietf.or= g

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/= listinfo/manet
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 manet= -request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 manet-o= wner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of manet digest..."


Today's Topics:

=C2=A0 =C2=A01. Thoughts on draft-dlep-lid (Henning Rogge)


-----------------------------------------------------------------= -----

Message: 1
Date: Thu, 7 Sep 2017 12:57:53 +0200
From: Henning Rogge <henning.rogge@fkie.fraunhofer.de>
To: <manet@ietf.org>
Subject: [manet] Thoughts on draft-dlep-lid
Message-ID: <a5f491d1-b094-a797-c9dd-2fcf0afe5e07@fkie.fraunhofer.<= wbr>de>
Content-Type: text/plain; charset=3D"utf-8"; format=3Dflowed

I had some time to look at draft-dlep-lid and there is one thing I am
wondering about.

I wonder if leaving out the MAC TLV is a bit too tough on many DLEP
implementations, we are talking about the "primary key" for the n= eighbors.

Whats about adding a "IP hops" TLV instead, which tells the route= r how
many IP hops a neighbor is away?

Default value would be zero (briding distance), but routing radios would report something like 2 (two routers in between, one on each radio).

This value might also be useful later for "multihop routing" radi= os.

Henning Rogge
--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f?r
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Zanderstrasse 5, 53177 Bonn, Germany
Telefon +4= 9 228 50212-469
mailto:henning.rogge@fk= ie.fraunhofer.de http://www.fkie.fraunhofer.de



------------------------------

Subject: Digest Footer

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


------------------------------

End of manet Digest, Vol 160, Issue 6
*************************************

--001a1148f6d4b43b170558a15944-- From nobody Thu Sep 7 22:25:18 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C05D13301E for ; Thu, 7 Sep 2017 22:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RtrWfPtgH1zF for ; Thu, 7 Sep 2017 22:25:14 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E492132D85 for ; Thu, 7 Sep 2017 22:25:14 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id h15so4066661qta.4 for ; Thu, 07 Sep 2017 22:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LkA8oUM22oiXbogfhFTuOzECjI1w7PbW8/ghI6aaNrg=; b=Yfat3tLX5YPWfCQPEoEOdAADk02w3NlnQ1pwmahTaM5Fv7z3Lz4/+S+uOtYAZFIPaL 4OOTPAkqaf1lD+HFV8tKm+uFNUzNKqEW3vTwOLt7+Jsu6ztTKwoXajWCiXiiwDlz7UFh K5nsSRBSt9oQX8bCR5YpbW0NuKULBB5q7K+wXqgj4OaewzimOfIIoVKQCKYFihlFMGSc afMyX9+1sdNb1PjEm7xvS9bnQZgJxKC+npWQUgXpT5U7zq/B5UTnSpG1iQDl1VziqXZQ ll6nemwYPS1xEECmQHLe7ft1Xf95EI1EDQ5sgqTrO2szO5c02BRueqjEyfnU4TcgmXOj kkaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LkA8oUM22oiXbogfhFTuOzECjI1w7PbW8/ghI6aaNrg=; b=SjC+bCrgVcNFDDVdUeBOuYLi7NIJC9U6exkmt2BbF3i3Q0ucd1CyWxQuqDXCyBUUpO a9JZBjDy3yZoU2tPnaWcD6qat0WH0GWXcbN/89bdw5K5+Or2Qk8Bg3PIYE0HgpX85d3v W3O1OzDjR77BojQmeS+4T0l6JnPB9iVUZG0VIutDqT99k093LgUl60+AK3FYsQC44cwD CWwdhvtTRq1HiJZKADQr9t0VkxpuKCRbbo4jLIXf5AfCGqDhU+MQSRoIHuHiQSFX2ha/ E/29KY3FLJB/f/ww1gJF8n0k/MmznyFHTvPz1xpVqZZ84zcskiQPxh+D16aO5zLUo9ow NmyA== X-Gm-Message-State: AHPjjUigy26HgjgQt/Dh3JH7xuMqHqNwjaPFQtZ6YYKyQ28gZuaYnueX wWw0M4rMfMnvXZEVRKfMu55vAxGR/rOpT++2LRY= X-Google-Smtp-Source: AOwi7QDIwUiDPNP0doF4c/V8R9p/+1X8zwow9OScgSV6YScgHvImw0COHGnO1DjX3ESfwloY3wzd6jHmkujeBEqS1pM= X-Received: by 10.200.51.237 with SMTP id d42mr2627713qtb.25.1504848313374; Thu, 07 Sep 2017 22:25:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.43.135 with HTTP; Thu, 7 Sep 2017 22:24:42 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Fri, 8 Sep 2017 07:24:42 +0200 Message-ID: To: "James A. (Jim) Stevens" Cc: MANET IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [manet] manet Digest, Vol 160, Issue 6 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 05:25:16 -0000 On Fri, Sep 8, 2017 at 12:55 AM, James A. (Jim) Stevens wrote: > what about radio routing hops below IP, e.g. for a mesh network below IP? > > This would tell the router how many radio hops (as contrasted to IP hops) > away a neighbor is. Good argument... maybe "this radio does IP routing" could be just a boolean flag (similar to "needs unicast traffic to determine MCS" and "does not support RX/TX broadcast/multicast" while this flag tells the router the number of radio hops to the target. Henning > > Jim Stevens > > > On Thu, Sep 7, 2017 at 2:00 PM, wrote: >> >> Send manet mailing list submissions to >> manet@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/manet >> or, via email, send a message with subject or body 'help' to >> manet-request@ietf.org >> >> You can reach the person managing the list at >> manet-owner@ietf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of manet digest..." >> >> >> Today's Topics: >> >> 1. Thoughts on draft-dlep-lid (Henning Rogge) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Thu, 7 Sep 2017 12:57:53 +0200 >> From: Henning Rogge >> To: >> Subject: [manet] Thoughts on draft-dlep-lid >> Message-ID: >> Content-Type: text/plain; charset="utf-8"; format=flowed >> >> I had some time to look at draft-dlep-lid and there is one thing I am >> wondering about. >> >> I wonder if leaving out the MAC TLV is a bit too tough on many DLEP >> implementations, we are talking about the "primary key" for the neighbors. >> >> Whats about adding a "IP hops" TLV instead, which tells the router how >> many IP hops a neighbor is away? >> >> Default value would be zero (briding distance), but routing radios would >> report something like 2 (two routers in between, one on each radio). >> >> This value might also be useful later for "multihop routing" radios. >> >> Henning Rogge >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f?r >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Zanderstrasse 5, 53177 Bonn, Germany >> Telefon +49 228 50212-469 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> >> >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> ------------------------------ >> >> End of manet Digest, Vol 160, Issue 6 >> ************************************* > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Fri Sep 8 02:17:59 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1711132ECD for ; Fri, 8 Sep 2017 02:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 lnoYdun_DUtk for ; Fri, 8 Sep 2017 02:17:56 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76731132EC9 for ; Fri, 8 Sep 2017 02:17:55 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Fri, 8 Sep 2017 10:17:31 +0100 From: Rick Taylor To: "manet@ietf.org" , "james.a.stevens@rockwellcollins.com" Thread-Topic: [manet] manet Digest, Vol 160, Issue 6 Thread-Index: AQHTKCxeb3y+1D4Hi0aoayjkZS1PLqKqpRsA Date: Fri, 8 Sep 2017 09:16:10 +0000 Message-ID: <1504862170.15735.11.camel@tropicalstormsoftware.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <1cc5838d-d73d-4fca-a322-0e9d2e10a6ab> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] manet Digest, Vol 160, Issue 6 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 09:17:57 -0000 SGkgSmFtZXMsDQoNClRoZXJlIHdhcyBhIGRyYWZ0IGV4dGVuc2lvbiB0aGF0IG1pZ2h0IGV4YWN0 bHkgbWVldCB5b3UgcmVxdWlyZW1lbnRzOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2Ry YWZ0LWNoZW5nLW1hbmV0LWRsZXAtbXVsdGktaG9wLWV4dGVuc2lvbi0wMA0KLnR4dA0KDQpDaGVl cnMNCg0KUmljayANCg0KDQpPbiBUaHUsIDIwMTctMDktMDcgYXQgMTc6NTUgLTA1MDAsIEphbWVz IEEuIChKaW0pIFN0ZXZlbnMgd3JvdGU6DQo+IHdoYXQgYWJvdXQgcmFkaW8gcm91dGluZyBob3Bz IGJlbG93IElQLCBlLmcuIGZvciBhIG1lc2ggbmV0d29yayBiZWxvdw0KPiBJUD8NCj4gDQo+IFRo aXMgd291bGQgdGVsbCB0aGUgcm91dGVyIGhvdyBtYW55IHJhZGlvIGhvcHMgKGFzIGNvbnRyYXN0 ZWQgdG8gSVANCj4gaG9wcykgYXdheSBhIG5laWdoYm9yIGlzLg0KPiANCj4gSmltIFN0ZXZlbnMN Cj4gDQo+IA0KPiBPbiBUaHUsIFNlcCA3LCAyMDE3IGF0IDI6MDAgUE0sIDxtYW5ldC1yZXF1ZXN0 QGlldGYub3JnPiB3cm90ZToNCj4gPiBTZW5kIG1hbmV0IG1haWxpbmcgbGlzdCBzdWJtaXNzaW9u cyB0bw0KPiA+IMKgIMKgIMKgIMKgIG1hbmV0QGlldGYub3JnDQo+ID4gDQo+ID4gVG8gc3Vic2Ny aWJlIG9yIHVuc3Vic2NyaWJlIHZpYSB0aGUgV29ybGQgV2lkZSBXZWIsIHZpc2l0DQo+ID4gwqAg wqAgwqAgwqAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KPiA+ IG9yLCB2aWEgZW1haWwsIHNlbmQgYSBtZXNzYWdlIHdpdGggc3ViamVjdCBvciBib2R5ICdoZWxw JyB0bw0KPiA+IMKgIMKgIMKgIMKgIG1hbmV0LXJlcXVlc3RAaWV0Zi5vcmcNCj4gPiANCj4gPiBZ b3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQNCj4gPiDCoCDCoCDC oCDCoCBtYW5ldC1vd25lckBpZXRmLm9yZw0KPiA+IA0KPiA+IFdoZW4gcmVwbHlpbmcsIHBsZWFz ZSBlZGl0IHlvdXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWMNCj4gPiB0aGFu ICJSZTogQ29udGVudHMgb2YgbWFuZXQgZGlnZXN0Li4uIg0KPiA+IA0KPiA+IA0KPiA+IFRvZGF5 J3MgVG9waWNzOg0KPiA+IA0KPiA+IMKgIMKgMS4gVGhvdWdodHMgb24gZHJhZnQtZGxlcC1saWQg KEhlbm5pbmcgUm9nZ2UpDQo+ID4gDQo+ID4gDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiAtLS0tLQ0KPiA+ IA0KPiA+IE1lc3NhZ2U6IDENCj4gPiBEYXRlOiBUaHUsIDcgU2VwIDIwMTcgMTI6NTc6NTMgKzAy MDANCj4gPiBGcm9tOiBIZW5uaW5nIFJvZ2dlIDxoZW5uaW5nLnJvZ2dlQGZraWUuZnJhdW5ob2Zl ci5kZT4NCj4gPiBUbzogPG1hbmV0QGlldGYub3JnPg0KPiA+IFN1YmplY3Q6IFttYW5ldF0gVGhv dWdodHMgb24gZHJhZnQtZGxlcC1saWQNCj4gPiBNZXNzYWdlLUlEOiA8YTVmNDkxZDEtYjA5NC1h Nzk3LWM5ZGQtMmZjZjBhZmU1ZTA3QGZraWUuZnJhdW5ob2Zlci5kDQo+ID4gZT4NCj4gPiBDb250 ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9InV0Zi04IjsgZm9ybWF0PWZsb3dlZA0KPiA+ IA0KPiA+IEkgaGFkIHNvbWUgdGltZSB0byBsb29rIGF0IGRyYWZ0LWRsZXAtbGlkIGFuZCB0aGVy ZSBpcyBvbmUgdGhpbmcgSQ0KPiA+IGFtDQo+ID4gd29uZGVyaW5nIGFib3V0Lg0KPiA+IA0KPiA+ IEkgd29uZGVyIGlmIGxlYXZpbmcgb3V0IHRoZSBNQUMgVExWIGlzIGEgYml0IHRvbyB0b3VnaCBv biBtYW55IERMRVANCj4gPiBpbXBsZW1lbnRhdGlvbnMsIHdlIGFyZSB0YWxraW5nIGFib3V0IHRo ZSAicHJpbWFyeSBrZXkiIGZvciB0aGUNCj4gPiBuZWlnaGJvcnMuDQo+ID4gDQo+ID4gV2hhdHMg YWJvdXQgYWRkaW5nIGEgIklQIGhvcHMiIFRMViBpbnN0ZWFkLCB3aGljaCB0ZWxscyB0aGUgcm91 dGVyDQo+ID4gaG93DQo+ID4gbWFueSBJUCBob3BzIGEgbmVpZ2hib3IgaXMgYXdheT8NCj4gPiAN Cj4gPiBEZWZhdWx0IHZhbHVlIHdvdWxkIGJlIHplcm8gKGJyaWRpbmcgZGlzdGFuY2UpLCBidXQg cm91dGluZyByYWRpb3MNCj4gPiB3b3VsZA0KPiA+IHJlcG9ydCBzb21ldGhpbmcgbGlrZSAyICh0 d28gcm91dGVycyBpbiBiZXR3ZWVuLCBvbmUgb24gZWFjaA0KPiA+IHJhZGlvKS4NCj4gPiANCj4g PiBUaGlzIHZhbHVlIG1pZ2h0IGFsc28gYmUgdXNlZnVsIGxhdGVyIGZvciAibXVsdGlob3Agcm91 dGluZyINCj4gPiByYWRpb3MuDQo+ID4gDQo+ID4gSGVubmluZyBSb2dnZQ0KPiA+IC0tDQo+ID4g RGlwbG9tLUluZm9ybWF0aWtlciBIZW5uaW5nIFJvZ2dlICwgRnJhdW5ob2Zlci1JbnN0aXR1dCBm P3INCj4gPiBLb21tdW5pa2F0aW9uLCBJbmZvcm1hdGlvbnN2ZXJhcmJlaXR1bmcgdW5kIEVyZ29u b21pZSBGS0lFDQo+ID4gS29tbXVuaWthdGlvbnNzeXN0ZW1lIChLT00pDQo+ID4gWmFuZGVyc3Ry YXNzZSA1LCA1MzE3NyBCb25uLCBHZXJtYW55DQo+ID4gVGVsZWZvbiArNDkgMjI4IDUwMjEyLTQ2 OQ0KPiA+IG1haWx0bzpoZW5uaW5nLnJvZ2dlQGZraWUuZnJhdW5ob2Zlci5kZSBodHRwOi8vd3d3 LmZraWUuZnJhdW5ob2Zlci4NCj4gPiBkZQ0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IA0KPiA+IFN1YmplY3Q6IERpZ2VzdCBGb290ZXIN Cj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+IG1hbmV0IG1haWxpbmcgbGlzdA0KPiA+IG1hbmV0QGlldGYub3JnDQo+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KPiA+IA0KPiA+IA0KPiA+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IA0KPiA+IEVuZCBvZiBtYW5ldCBEaWdl c3QsIFZvbCAxNjAsIElzc3VlIDYNCj4gPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqDQo+ID4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4gbWFuZXRAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA== From nobody Fri Sep 8 02:35:50 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD7613236D for ; Fri, 8 Sep 2017 02:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 XApt2g51B-Dp for ; Fri, 8 Sep 2017 02:35:48 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC153132ECF for ; Fri, 8 Sep 2017 02:35:47 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Fri, 8 Sep 2017 10:35:24 +0100 From: Rick Taylor To: "henning.rogge@fkie.fraunhofer.de" , "manet@ietf.org" Thread-Topic: Thoughts on draft-dlep-lid Thread-Index: AQHTJ8grk2fa7Bfen0q1nnIT6M2vfKKqquOA Date: Fri, 8 Sep 2017 09:34:03 +0000 Message-ID: <1504863243.15735.13.camel@tropicalstormsoftware.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <5d8f0e6b-b7c6-4508-b8be-43db48d73271> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 09:35:50 -0000 SGkgSGVubmluZywNCg0KVGhlIExJRCBkcmFmdCBpcyBhY3R1YWxseSBhbiBhbWFsZ2FtYXRpb24g b2YgYSAyIHJvdWdoIGRyYWZ0cyBJIHdhcw0Kd29ya2luZyBvbiB0byBzb2x2ZSB0d28gZGlmZmVy ZW50IHVzZS1jYXNlcywgYW5kIFN0YW4gY29ycmVjdGx5IHBvaW50ZWQNCiBvdXQgdGhlIHNvbHV0 aW9uIHdhcyB0aGUgc2FtZToNCg0KMSkgVGhlcmUgaXMgc29tZSBiYWNraGF1bCBuZXR3b3JrIGFj Y2Vzc2libGUgdmlhIGEgcmFkaW8sIHdoZXJlIHRoZQ0KdXBzdHJlYW0gcm91dGVyIGRvZXMgbm90 IHJlYWxseSBleGlzdCBpbiBETEVQIHRlcm1zLCBpdCBjZXJ0YWlubHkNCmRvZXNuJ3QgaGF2ZSBh IHJlYWNoYWJsZSBNQUMsIGFuZCB3b24ndCBwZXJmb3JtIGFueSBraW5kIG9mIHJvdXRpbmcNCnBy b3RvY29sIHBlZXJpbmcuICBCdXQsIHRoZXJlIGlzIGRlZmluaXRlbHkgYSBsaW5rIHRoYXQgY2Fu IGNvbWUgYW5kDQpnbywgYW5kIG1ldHJpY3MgYWJvdXQgdGhlIGxpbmsgYXJlIHZhbGlkLiAgQW4g ZXhhbXBsZSBjb3VsZCBiZSAzRy4gIEENCkRMRVAgZGVzdGluYXRpb24gZXhpc3RzLCBpdCBoYXMg cm91dGVzIGFuZCBhZGRyZXNzZXMsIGJ1dCBubyBNQUMuDQoNCjIpIEV4aXN0aW5nIHJhZGlvIHN5 c3RlbXMgdGhhdCBtZXNoIGF0IGxheWVyLTMuICBUaGVzZSByYWRpbyBzeXN0ZW1zDQpjYW4gYWxz byBzdXBwbHkgdmFsaWQgRExFUCBpbmZvcm1hdGlvbiwgYnV0IGFnYWluLCB0aGVyZSBhcmUgbm8g TUFDDQphZGRyZXNzZXMgdGhhdCBtYWtlIGFueSBzZW5zZS4gKFRoaXMgd2FzIHRoZSBvbGQgTGF5 ZXItMyBETEVQDQpleHRlbnNpb24pDQoNCkkgdHJpZWQgZm9yIHNvbWUgdGltZSB0byBrZWVwIHRo ZSBETEVQIE1BQyBhZGRyZXNzIERhdGEgSXRlbSBhcyB0aGUNCidwcmltYXJ5IGtleScsIGluaXRp YWxseSBieSBoYXZpbmcgYW4gZXh0cmEgZGF0YSBpdGVtOiAiVGhpcyBNQUMgaXMgbm90DQphIE1B QyIsIGJ1dCB0aGUgZW5kIHJlc3VsdCBpcyB0aGUgc2FtZS4gIFRvIHN1cHBvcnQgTElEcywgc29t ZXdoZXJlIGluDQp5b3VyIERMRVAgaW5mb3JtYXRpb24gYmFzZSB5b3UgbmVlZCBhIGZpZWxkIGFz c29jaWF0ZWQgd2l0aCB5b3VyDQpEZXN0aW5hdGlvbiB0aGF0IHNwZWNpZmllcyB3aGV0aGVyIHRo ZSBJRCBpcyBhIE1BQyBvciBub3QuDQoNCkFmdGVyIGV4dGVuc2l2ZSBkaXNjdXNzaW9uIHdpdGgg U3RhbiBhbmQgS2VpdGggTW9yZ2FuIChvbiBsaXN0IDMxLzUvMTcNCm9ud2FyZHMpLCBJIHdhcyBj b252aW5jZWQgdGhhdCBhIHNlcGFyYXRlIERhdGEgSXRlbSwgcmVwbGFjaW5nIHRoZSBNQUMsDQpi dXQgb2YgdGhlIHNhbWUgYnl0ZS1sZW5ndGggYXMgdGhlIE1BQyB3YXMgdGhlIG1vc3QgZWxlZ2Fu dCBzb2x1dGlvbi4gDQpCdXQgSSdtIG5vdCBmaXhlZCBpbiBteSBvcGluaW9uLCAgaWYgdGhlIFdH IHdhbnRzIHRvIGFkb3B0IHRoaXMNCmV4dGVuc2lvbiwgYW5kIHRoZSBjb25zZW5zdXMgaXMgdGhh dCBhbiBleHRyYSAiTm90LU1BQyIgZGF0YSBpdGVtIGlzDQp0aGUgYmV0dGVyIHdheSB0byBnbywg dGhlbiBzbyBiZSBpdC4NCg0KU28gaW4gY29uY2x1c2lvbiwgdGhlIExJRCBleHRlbnNpb24gcHJv cG9zZXMgbG9vc2VuaW5nIHRoZSBkZWZpbml0aW9uDQpvZiB0aGUgJ3ByaW1hcnkga2V5JyBmb3Ig eW91ciBEZXN0aW5hdGlvbnMgZnJvbSAnVGhleSBhcmUgTGF5ZXItMg0KYWRkcmVzc2VzL01BQ3Mn IHRvICdUaGV5IGFyZSBmaXhlZCBsZW5ndGggaWRlbnRpZmllcnMsIHNvbWUgb2Ygd2hpY2gNCmFy ZSBNQUNzJy4gIEFuZCB0aGUgZXh0ZW5zaW9uIGRlZmluZXMgaG93IGEgcGVlciBjYW4gZGlmZmVy ZW50aWF0ZQ0KYmV0d2VlbiB0aGVtLg0KDQpDaGVlcnMsDQoNClJpY2s= From nobody Fri Sep 8 02:37:46 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FAF132ED1 for ; Fri, 8 Sep 2017 02:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 R1d_AEkSCZUH for ; Fri, 8 Sep 2017 02:37:42 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B1613236D for ; Fri, 8 Sep 2017 02:37:41 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id r141so5002345qke.2 for ; Fri, 08 Sep 2017 02:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ur1FbksbcgwAe+duRzGtJt2Urbs2obT3DBnelvzL+cs=; b=frKvuxXFJ6YnZu6PXcI+wb/amsy/6rvoKDuXdXZlyuZcBeRDQapQWU94Bh2iy7kYgY 6autNY2P+DvoSxf303axK/izX05QMBGbl7N3zsMX7wzoe792VT6RHtaOXUHnWVgp9HxH UbnCrHmtK1xilCGOXPW6okKr8hqVCBFXwciPcFw7OzieerloQ8x765ffj0yMu9K1Mxvx 5r/coQ5n4lFmtYuVKTtB9Jveb5l9C+SxNcgs9Vwu33CzeMZAwNRlI0yHqu/VCRNjNZhh dN9jUmsHnNlm/PYYEb/SawuWh1eLbb9pTxzNwYw5xp+PYesmqw10pt0kdpf84Tb2q93L ZVIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ur1FbksbcgwAe+duRzGtJt2Urbs2obT3DBnelvzL+cs=; b=mE1BQk0EBT52+UaVai9HrAQHcZiU0W5PpwvztX9enTiozqFC1TwT6g2tbm349gSq1B HQU2ePsm2YguUFvRnZ5GuVc5M7GY1QffDO5N9hWuDuU31Y8FFxyZ/noGYuRp8Tb5UPAE wljAkd7bWHhmAYGwz1bcwlB6n4LnjY5GcUPE0RpDQTHmIsVfixvPKKxWIyJiDViQJAXR AVycXzA4X+LHn3/q6Ra5aOpMruHKsJyTresZvl/FxTLA0V37RKVq11wXilqfCAq/tHmG mScg/Lke3jW8Y3aOIJd6KVPU7IUqyPOJO2PcHvVK2lQ/1gGrhWQoRUfjV1Wjgu9agENc vi8A== X-Gm-Message-State: AHPjjUgUEnqPFAcpxlcNf3VdlogUD/6nmnQgncw+S0s1hp6kmKt4LO3v bdKDkQx3p7llRh6udZt/+FoaqURF32sA7X3xdhI= X-Google-Smtp-Source: AOwi7QAgq89hVzm2PrinSuf7HwL7YEPMoEPDMuSg/AFmPtKtFrMTSwteRuMzOYKpyYcGM9BA6ulXn43SVg1ItZrZu0c= X-Received: by 10.55.27.66 with SMTP id b63mr2784901qkb.338.1504863461018; Fri, 08 Sep 2017 02:37:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.43.135 with HTTP; Fri, 8 Sep 2017 02:37:10 -0700 (PDT) In-Reply-To: <1504862170.15735.11.camel@tropicalstormsoftware.com> References: <1504862170.15735.11.camel@tropicalstormsoftware.com> From: Henning Rogge Date: Fri, 8 Sep 2017 11:37:10 +0200 Message-ID: To: Rick Taylor Cc: "manet@ietf.org" , "james.a.stevens@rockwellcollins.com" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [manet] manet Digest, Vol 160, Issue 6 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 09:37:44 -0000 On Fri, Sep 8, 2017 at 11:16 AM, Rick Taylor wrote: > Hi James, > > There was a draft extension that might exactly meet you requirements: > > https://tools.ietf.org/id/draft-cheng-manet-dlep-multi-hop-extension-00 > .txt I knew I had forgot something... So this draft could be combined with a "IP routing" flag of the radio? I am still a little bit worried about the "id" draft that removes the mandatory MAC tlv from the Neighbor up/down/update messages. Henning > > Cheers > > Rick > > > On Thu, 2017-09-07 at 17:55 -0500, James A. (Jim) Stevens wrote: >> what about radio routing hops below IP, e.g. for a mesh network below >> IP? >> >> This would tell the router how many radio hops (as contrasted to IP >> hops) away a neighbor is. >> >> Jim Stevens >> >> >> On Thu, Sep 7, 2017 at 2:00 PM, wrote: >> > Send manet mailing list submissions to >> > manet@ietf.org >> > >> > To subscribe or unsubscribe via the World Wide Web, visit >> > https://www.ietf.org/mailman/listinfo/manet >> > or, via email, send a message with subject or body 'help' to >> > manet-request@ietf.org >> > >> > You can reach the person managing the list at >> > manet-owner@ietf.org >> > >> > When replying, please edit your Subject line so it is more specific >> > than "Re: Contents of manet digest..." >> > >> > >> > Today's Topics: >> > >> > 1. Thoughts on draft-dlep-lid (Henning Rogge) >> > >> > >> > ----------------------------------------------------------------- >> > ----- >> > >> > Message: 1 >> > Date: Thu, 7 Sep 2017 12:57:53 +0200 >> > From: Henning Rogge >> > To: >> > Subject: [manet] Thoughts on draft-dlep-lid >> > Message-ID: > > e> >> > Content-Type: text/plain; charset="utf-8"; format=flowed >> > >> > I had some time to look at draft-dlep-lid and there is one thing I >> > am >> > wondering about. >> > >> > I wonder if leaving out the MAC TLV is a bit too tough on many DLEP >> > implementations, we are talking about the "primary key" for the >> > neighbors. >> > >> > Whats about adding a "IP hops" TLV instead, which tells the router >> > how >> > many IP hops a neighbor is away? >> > >> > Default value would be zero (briding distance), but routing radios >> > would >> > report something like 2 (two routers in between, one on each >> > radio). >> > >> > This value might also be useful later for "multihop routing" >> > radios. >> > >> > Henning Rogge >> > -- >> > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f?r >> > Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> > Kommunikationssysteme (KOM) >> > Zanderstrasse 5, 53177 Bonn, Germany >> > Telefon +49 228 50212-469 >> > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer. >> > de >> > >> > >> > >> > ------------------------------ >> > >> > Subject: Digest Footer >> > >> > _______________________________________________ >> > manet mailing list >> > manet@ietf.org >> > https://www.ietf.org/mailman/listinfo/manet >> > >> > >> > ------------------------------ >> > >> > End of manet Digest, Vol 160, Issue 6 >> > ************************************* >> > >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Fri Sep 8 02:39:40 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2244132ED1 for ; Fri, 8 Sep 2017 02:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7EAXa41JJt0K for ; Fri, 8 Sep 2017 02:39:37 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B8A6132ECF for ; Fri, 8 Sep 2017 02:39:37 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id s18so3270925qta.3 for ; Fri, 08 Sep 2017 02:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uRkvibnyny+DQYRzB9+8YiUJyC09L8ATAwpQy5GDuJ0=; b=eMVjC4MXG7Leio+/ZpWXsjKlnuUckrzeAAYxC4CfnogJCFR9lpbK8bXyUFdmKcitcJ Or0MeOGyYBfU0hAFN3u8p4da/5CYBBuFkMIUT8N5SSGaiVtNXQ/XJN4wJJ3lLjtdAJL7 s5HHiPoka8L8pyIMG+k9iJXjZDWwLEf9P+yuL61sMCz6sh57xR2XMeWw2FcwLdDUbg/T CDxarBSnUIK8PyxhhwJxwW9FJSiQAey83m/SIQx1p3kMZF1xwQh/BIE0JaieLcZ9GXQZ qD+KlAbTybaDKO39CWZv37If/t6l5bZXNDYc4Fesmol7n090ojlfnzF/eQQXjZ6OoYQp VxNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uRkvibnyny+DQYRzB9+8YiUJyC09L8ATAwpQy5GDuJ0=; b=E8roPYqzZ4VdNaJrZTKNL10k+nr/1H9iLi7FV9Tpy3z6lkeR0bpiZLDzlzhJZfqwf6 z1SkPjqtYyySdCHBkUjQyb1NqaDyOegIgfbclZraGyMzLbm3vYxPR9gQYIDFUN1TCBjL jo2seSmpCEnELZfHZYeOnARg7Bgf40dZOfLY6hxXaGpSv5PzCba1TLW2jWmvyhzzBTY/ dSFtidDKB3Log/KET1bVqxpKqF7niN/gc4ZEKu/Ex6rySI9ryAbrFtFkcedCF36F9X98 WezKnjpCP29tfTMyljjlZO3elZndSIRxmrHU4wlvMeOmhbcOq2zZjs6cy1q6jiJYaBpV OCIw== X-Gm-Message-State: AHPjjUgtmGhuI1VZR0+p/WKEO7Qts8/7P9smgX9EJUs4iKqAJI/vzT86 RZ0F7SXH6uV3ClV3avvtDMXPG5+9SYsaos+sM1LkMw== X-Google-Smtp-Source: AOwi7QCkQT9GGbbTDdu4snBfVTJtObIDQKMFCtAKiQmGA9xIPDfeyurD/GeRuwaPnbJawekEHzpp4LVc2EeG3RJqSfI= X-Received: by 10.200.40.20 with SMTP id 20mr2977399qtq.324.1504863576468; Fri, 08 Sep 2017 02:39:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.43.135 with HTTP; Fri, 8 Sep 2017 02:39:06 -0700 (PDT) In-Reply-To: <1504863243.15735.13.camel@tropicalstormsoftware.com> References: <1504863243.15735.13.camel@tropicalstormsoftware.com> From: Henning Rogge Date: Fri, 8 Sep 2017 11:39:06 +0200 Message-ID: To: Rick Taylor Cc: "henning.rogge@fkie.fraunhofer.de" , "manet@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 09:39:39 -0000 On Fri, Sep 8, 2017 at 11:34 AM, Rick Taylor wrote: > Hi Henning, > > The LID draft is actually an amalgamation of a 2 rough drafts I was > working on to solve two different use-cases, and Stan correctly pointed > out the solution was the same: > > 1) There is some backhaul network accessible via a radio, where the > upstream router does not really exist in DLEP terms, it certainly > doesn't have a reachable MAC, and won't perform any kind of routing > protocol peering. But, there is definitely a link that can come and > go, and metrics about the link are valid. An example could be 3G. A > DLEP destination exists, it has routes and addresses, but no MAC. > > 2) Existing radio systems that mesh at layer-3. These radio systems > can also supply valid DLEP information, but again, there are no MAC > addresses that make any sense. (This was the old Layer-3 DLEP > extension) > > I tried for some time to keep the DLEP MAC address Data Item as the > 'primary key', initially by having an extra data item: "This MAC is not > a MAC", but the end result is the same. To support LIDs, somewhere in > your DLEP information base you need a field associated with your > Destination that specifies whether the ID is a MAC or not. > > After extensive discussion with Stan and Keith Morgan (on list 31/5/17 > onwards), I was convinced that a separate Data Item, replacing the MAC, > but of the same byte-length as the MAC was the most elegant solution. > But I'm not fixed in my opinion, if the WG wants to adopt this > extension, and the consensus is that an extra "Not-MAC" data item is > the better way to go, then so be it. > > So in conclusion, the LID extension proposes loosening the definition > of the 'primary key' for your Destinations from 'They are Layer-2 > addresses/MACs' to 'They are fixed length identifiers, some of which > are MACs'. And the extension defines how a peer can differentiate > between them. In fact we do something similar here, "inventing" a (non-global) MAC for transmitting metrics for IP destinations. As I said in the other mail, I am just a bit worried about removing a mandatory TLV from a message. Henning From nobody Fri Sep 8 02:53:56 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70E4132ED1 for ; Fri, 8 Sep 2017 02:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bNza4Jmiznzc for ; Fri, 8 Sep 2017 02:53:54 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F99132ED0 for ; Fri, 8 Sep 2017 02:53:54 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id r141so5073301qke.2 for ; Fri, 08 Sep 2017 02:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=A8hqXe8APzlE7tVgZT58eSTIV5ipcy+R/br3uyWRaQg=; b=I9kxlfBHXqkchtsYPT6dPf14SYU/h3BLaPm3h4t9YMtVojb71XVl2GFSqTckErTDCS xkviilh8nlGZx8EQor3ewau/dU6SrxImL81UNKiew2WiVVLbxwlHZOUGp1ayvg8cwNLl pWbZza21VSP4G+JiPHKwDWrHExkQNt/9uEYhu7TYrdmBX3EacOHSX9YW2oiFIH5UmPVZ j72mYkG0u0VXk4QR5NBkmwWz4tyfijIVk81qsyrc0vYujERnlYsvIyORTtvuvrRe6bPL GgA59JYgnSwm0yAFae4tNrGPZBZ9jC8NFbA1aZs1fnF96IYf8vKaH27fky8qvLBH5W1y Afkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=A8hqXe8APzlE7tVgZT58eSTIV5ipcy+R/br3uyWRaQg=; b=my4w7MeSslUzxtllirNNBeYuxOeEmMLWWwSABDkoPkG91z/QGCSJ/3FXsOo5zy6f8/ hKdn6uMgi/l9WirING3Olv9z2e5lwkx6px+q6nUGURYWp43/v0Vj5mW6d8UjF2jxm0hC Tq0wYwS0VI5UhOqRb/myIJaUbspBj0c2DD9hJDZIjlyW4qFEzePt+sDyVUzpF5LZvmJY BRAiAJsXFV4AAA55fhmT4bgWiZs8BZ0qYAwfHMWSjp0H1ztcgJTwXZ/CLCDJ+i7cQspy mMYvyTATgW9g3eEMVlVczjEwLNaQBGkHayutnVMAYpNgH0iszbpyrCNOtVLWXuYCk4Fb K2VQ== X-Gm-Message-State: AHPjjUj3IZ/fXNg16Vnre/zmmJ7+g7/Rl29fUE0offLFI42H/Hd8VkmJ /VuV/7HQLaKvoWLZE8RIdqq56vEc4gU42SM70VA= X-Google-Smtp-Source: AOwi7QDRBfD8g64fbtHumeF9N2dB2S58ADZdojB8M8cfoM8TZcIPQWrQT1BZ4C6iJFdXfTKX/aznVBYDQJbm2kvHTuE= X-Received: by 10.55.167.144 with SMTP id q138mr2985829qke.74.1504864433414; Fri, 08 Sep 2017 02:53:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.43.135 with HTTP; Fri, 8 Sep 2017 02:53:22 -0700 (PDT) In-Reply-To: References: <1500890455.2721.234.camel@tropicalstormsoftware.com> <1504171326.31980.2.camel@tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801D30BA2E9@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801D30BD277@tss-server1.home.tropicalstormsoftware.com> <275b3ace-23c6-7db1-3bb8-07dbafdde5d5@fkie.fraunhofer.de> <1504603998.15735.9.camel@tropicalstormsoftware.com> From: Henning Rogge Date: Fri, 8 Sep 2017 11:53:22 +0200 Message-ID: To: Stan Ratliff Cc: Rick Taylor , "manet@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [manet] New DLEP extension drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 09:53:56 -0000 On Tue, Sep 5, 2017 at 6:54 PM, Stan Ratliff wrote: >> Do you fancy starting a 'local modem capabilities announcement' draft? > > I'd prefer (and am volunteering to help) making it a "capabilities draft" - > one that encompasses both 'local' and 'remote' capabilities. I think the > scope is manageable, I am currently upgrading my DLEP implementation to process "boolean" values in TLVs... I want to do some tests with the "radio attributes" before I start the draft. At the moment I have three radio (interface) attributes, but no "neighbor" ones: * MCS-by-unicast (radio needs unicast traffic to destination to determine link speed) * RX-unicast-only (radio will only receive unicast, but no multicast/broadcast) * TX-unicast-only (radio cannot transmit multicast/broadcast) Henning From nobody Fri Sep 8 02:59:09 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B33132403 for ; Fri, 8 Sep 2017 02:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 kxds7WufhdKO for ; Fri, 8 Sep 2017 02:59:06 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0AE132ED0 for ; Fri, 8 Sep 2017 02:59:05 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Fri, 8 Sep 2017 10:58:40 +0100 From: Rick Taylor To: "hrogge@gmail.com" CC: "henning.rogge@fkie.fraunhofer.de" , "manet@ietf.org" Thread-Topic: [manet] Thoughts on draft-dlep-lid Thread-Index: AQHTKIZj53J9/AH/OUGjxC7M5WHHyKKqr+gA Date: Fri, 8 Sep 2017 09:57:20 +0000 Message-ID: <1504864640.15735.14.camel@tropicalstormsoftware.com> References: <1504863243.15735.13.camel@tropicalstormsoftware.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 09:59:07 -0000 T24gRnJpLCAyMDE3LTA5LTA4IGF0IDExOjM5ICswMjAwLCBIZW5uaW5nIFJvZ2dlIHdyb3RlOg0K PiBPbiBGcmksIFNlcCA4LCAyMDE3IGF0IDExOjM0IEFNLCBSaWNrIFRheWxvcg0KPiA8cmlja0B0 cm9waWNhbHN0b3Jtc29mdHdhcmUuY29tPiB3cm90ZToNCj4gPiBIaSBIZW5uaW5nLA0KPiA+IA0K PiA+IFRoZSBMSUQgZHJhZnQgaXMgYWN0dWFsbHkgYW4gYW1hbGdhbWF0aW9uIG9mIGEgMiByb3Vn aCBkcmFmdHMgSSB3YXMNCj4gPiB3b3JraW5nIG9uIHRvIHNvbHZlIHR3byBkaWZmZXJlbnQgdXNl LWNhc2VzLCBhbmQgU3RhbiBjb3JyZWN0bHkNCj4gPiBwb2ludGVkDQo+ID4gwqBvdXQgdGhlIHNv bHV0aW9uIHdhcyB0aGUgc2FtZToNCj4gPiANCj4gPiAxKSBUaGVyZSBpcyBzb21lIGJhY2toYXVs IG5ldHdvcmsgYWNjZXNzaWJsZSB2aWEgYSByYWRpbywgd2hlcmUgdGhlDQo+ID4gdXBzdHJlYW0g cm91dGVyIGRvZXMgbm90IHJlYWxseSBleGlzdCBpbiBETEVQIHRlcm1zLCBpdCBjZXJ0YWlubHkN Cj4gPiBkb2Vzbid0IGhhdmUgYSByZWFjaGFibGUgTUFDLCBhbmQgd29uJ3QgcGVyZm9ybSBhbnkg a2luZCBvZiByb3V0aW5nDQo+ID4gcHJvdG9jb2wgcGVlcmluZy7CoMKgQnV0LCB0aGVyZSBpcyBk ZWZpbml0ZWx5IGEgbGluayB0aGF0IGNhbiBjb21lDQo+ID4gYW5kDQo+ID4gZ28sIGFuZCBtZXRy aWNzIGFib3V0IHRoZSBsaW5rIGFyZSB2YWxpZC7CoMKgQW4gZXhhbXBsZSBjb3VsZCBiZQ0KPiA+ IDNHLsKgwqBBDQo+ID4gRExFUCBkZXN0aW5hdGlvbiBleGlzdHMsIGl0IGhhcyByb3V0ZXMgYW5k IGFkZHJlc3NlcywgYnV0IG5vIE1BQy4NCj4gPiANCj4gPiAyKSBFeGlzdGluZyByYWRpbyBzeXN0 ZW1zIHRoYXQgbWVzaCBhdCBsYXllci0zLsKgwqBUaGVzZSByYWRpbw0KPiA+IHN5c3RlbXMNCj4g PiBjYW4gYWxzbyBzdXBwbHkgdmFsaWQgRExFUCBpbmZvcm1hdGlvbiwgYnV0IGFnYWluLCB0aGVy ZSBhcmUgbm8gTUFDDQo+ID4gYWRkcmVzc2VzIHRoYXQgbWFrZSBhbnkgc2Vuc2UuIChUaGlzIHdh cyB0aGUgb2xkIExheWVyLTMgRExFUA0KPiA+IGV4dGVuc2lvbikNCj4gPiANCj4gPiBJIHRyaWVk IGZvciBzb21lIHRpbWUgdG8ga2VlcCB0aGUgRExFUCBNQUMgYWRkcmVzcyBEYXRhIEl0ZW0gYXMg dGhlDQo+ID4gJ3ByaW1hcnkga2V5JywgaW5pdGlhbGx5IGJ5IGhhdmluZyBhbiBleHRyYSBkYXRh IGl0ZW06ICJUaGlzIE1BQyBpcw0KPiA+IG5vdA0KPiA+IGEgTUFDIiwgYnV0IHRoZSBlbmQgcmVz dWx0IGlzIHRoZSBzYW1lLsKgwqBUbyBzdXBwb3J0IExJRHMsIHNvbWV3aGVyZQ0KPiA+IGluDQo+ ID4geW91ciBETEVQIGluZm9ybWF0aW9uIGJhc2UgeW91IG5lZWQgYSBmaWVsZCBhc3NvY2lhdGVk IHdpdGggeW91cg0KPiA+IERlc3RpbmF0aW9uIHRoYXQgc3BlY2lmaWVzIHdoZXRoZXIgdGhlIElE IGlzIGEgTUFDIG9yIG5vdC4NCj4gPiANCj4gPiBBZnRlciBleHRlbnNpdmUgZGlzY3Vzc2lvbiB3 aXRoIFN0YW4gYW5kIEtlaXRoIE1vcmdhbiAob24gbGlzdA0KPiA+IDMxLzUvMTcNCj4gPiBvbndh cmRzKSwgSSB3YXMgY29udmluY2VkIHRoYXQgYSBzZXBhcmF0ZSBEYXRhIEl0ZW0sIHJlcGxhY2lu ZyB0aGUNCj4gPiBNQUMsDQo+ID4gYnV0IG9mIHRoZSBzYW1lIGJ5dGUtbGVuZ3RoIGFzIHRoZSBN QUMgd2FzIHRoZSBtb3N0IGVsZWdhbnQNCj4gPiBzb2x1dGlvbi4NCj4gPiBCdXQgSSdtIG5vdCBm aXhlZCBpbiBteSBvcGluaW9uLMKgwqBpZiB0aGUgV0cgd2FudHMgdG8gYWRvcHQgdGhpcw0KPiA+ IGV4dGVuc2lvbiwgYW5kIHRoZSBjb25zZW5zdXMgaXMgdGhhdCBhbiBleHRyYSAiTm90LU1BQyIg ZGF0YSBpdGVtDQo+ID4gaXMNCj4gPiB0aGUgYmV0dGVyIHdheSB0byBnbywgdGhlbiBzbyBiZSBp dC4NCj4gPiANCj4gPiBTbyBpbiBjb25jbHVzaW9uLCB0aGUgTElEIGV4dGVuc2lvbiBwcm9wb3Nl cyBsb29zZW5pbmcgdGhlDQo+ID4gZGVmaW5pdGlvbg0KPiA+IG9mIHRoZSAncHJpbWFyeSBrZXkn IGZvciB5b3VyIERlc3RpbmF0aW9ucyBmcm9tICdUaGV5IGFyZSBMYXllci0yDQo+ID4gYWRkcmVz c2VzL01BQ3MnIHRvICdUaGV5IGFyZSBmaXhlZCBsZW5ndGggaWRlbnRpZmllcnMsIHNvbWUgb2YN Cj4gPiB3aGljaA0KPiA+IGFyZSBNQUNzJy7CoMKgQW5kIHRoZSBleHRlbnNpb24gZGVmaW5lcyBo b3cgYSBwZWVyIGNhbiBkaWZmZXJlbnRpYXRlDQo+ID4gYmV0d2VlbiB0aGVtLg0KPiANCj4gSW4g ZmFjdCB3ZSBkbyBzb21ldGhpbmcgc2ltaWxhciBoZXJlLCAiaW52ZW50aW5nIiBhIChub24tZ2xv YmFsKSBNQUMNCj4gZm9yIHRyYW5zbWl0dGluZyBtZXRyaWNzIGZvciBJUCBkZXN0aW5hdGlvbnMu DQoNCkl0IHNlZW1zIHRvIGJlIHRoZSBjb21tb24gd29yay1hcm91bmQuDQoNCj4gDQo+IEFzIEkg c2FpZCBpbiB0aGUgb3RoZXIgbWFpbCwgSSBhbSBqdXN0IGEgYml0IHdvcnJpZWQgYWJvdXQgcmVt b3ZpbmcgYQ0KPiBtYW5kYXRvcnkgVExWIGZyb20gYSBtZXNzYWdlLg0KDQpBbmQgdGhhdCBjb3Vs ZCBiZSBhIGdvb2QgcmVhc29uIGZvciBoYXZpbmcgdGhlICdOb3QtTUFDJyBkYXRhIGl0ZW0NCmlu c3RlYWQuLi4NCg0KUmljaw0K From nobody Fri Sep 8 03:11:24 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB01132ED5 for ; Fri, 8 Sep 2017 03:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 55p6fgjaTr1g for ; Fri, 8 Sep 2017 03:11:21 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B53132ED3 for ; Fri, 8 Sep 2017 03:11:21 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Fri, 8 Sep 2017 11:10:56 +0100 From: Rick Taylor To: "manet@ietf.org" Thread-Topic: DLEP extensions and capabilities Thread-Index: AQHTKIrCb/U8kjLIB0aqVIA/3jOfEw== Date: Fri, 8 Sep 2017 10:09:35 +0000 Message-ID: <1504865375.15735.17.camel@tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <986c7b79-13fc-42d5-ab0e-86c30005425f> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [manet] DLEP extensions and capabilities X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 10:11:23 -0000 SGkgQWxsLA0KDQpJJ3ZlIGJlZW4gbXVsbGluZyBvdmVyIGhvdyBvbmUgbWlnaHQgaW1wbGVtZW50 IGFuIGV4dGVuc2lvbiB0aGF0IGFsbG93cw0KYSBETEVQIHBlZXIgdG8gYWR2ZXJ0aXNlIGl0cyBj YXBhYmlsaXRpZXMsIGFzIGRlc2lyZWQgYnkgU3RhbiBhbmQNCkhlbm5pbmcuICBJJ2xsIHN0aWNr IHRvIGxvY2FsIGNhcGFiaWxpdGllcyBmb3Igbm93LCB0byBzY29wZSB0aGUNCnByb2JsZW0gYSBs aXR0bGUuDQoNClNvLCBhbiBvYnZpb3VzIHdheSB0byBkbyB0aGlzIHdvdWxkIGJlIHRvIGNyZWF0 ZSBhbiBFeHRlbnNpb24gJ0xvY2FsDQpDYXBzJy4gIFRoaXMgZXh0ZW5zaW9uIHdvdWxkIGRlZmlu ZSBhIG5ldyBEYXRhIEl0ZW0sIHRoYXQgbGlzdHMgdGhlDQpjYXBhYmlsaXRpZXMsIGVhY2ggZGVm aW5lZCBieSBhIG51bWJlciBpbiBhIG5ldyBJQU5BIHJlZ2lzdHJ5LiAgVGhpcw0KRGF0YSBJdGVt IGlzIHVzZWQgZHVyaW5nIFNlc3Npb24gSW5pdCB0byBhbm5vdW5jZSBjYXBhYmlsaXR5Lg0KDQpI b3dldmVyLCB0aGlzIGxvb2tzIHJlbWFya2FibHkgbGlrZSB0aGUgZXh0ZW5zaW9uIG1lY2hhbmlz bSBpdHNlbGYuIA0KV291bGQgaXQgcGVyaGFwcyBiZSBtb3JlIHNlbnNpYmxlIHRvIHJlZ2lzdGVy IGRldmljZSBjYXBhYmlsaXRpZXMgYXMNCmV4dGVuc2lvbnMgaW4gdGhlaXIgb3duIHJpZ2h0LCBp LmUuIGluIHRoZSBJQU5BIERMRVAgRXh0ZW5zaW9uDQpSZWdpc3RyeS4gIFNvIGEgbW9kZW0gdGhh dCBzdXBwb3J0cyAnb24tZGVtYW5kJyBkYXRhIHJhdGVzLCB3b3VsZA0KYWR2ZXJ0aXNlIGFuICdP biBkZW1hbmQnIGV4dGVuc2lvbiwgYW5kIGEgcm91dGVyIHRoYXQgY2FuIGRvIHNvbWV0aGluZw0K c2Vuc2libGUgd2l0aCAnT24gZGVtYW5kJyBkYXRhIHJhdGVzIGFsc28gYWR2ZXJ0aXNlcyBzdXBw b3J0LiAgSWYgdGhlDQptb2RlbSBkZXRlY3RzIHRoYXQgaXQncyB0YWxraW5nIHRvIGEgcm91dGVy IHRoYXQgZG9lc24ndCB1bmRlcnN0YW5kDQonT24tZGVtYW5kJyB0aGVuIGl0IGNvdWxkIGFubm91 bmNlIGFuIGFydGlmaWNhbCBkYXRhIHJhdGUgYXMgQ0RSDQppbnN0ZWFkIG9mIDAuDQoNCkkgc2Vl IHRoZSBleHRlbnNpb25zLW9ubHkgbWVjaGFuaXNtIGFzIGhhdmluZyBzb21lIGFkdmFudGFnZXM6 DQoNCjEpIEl0IGFsbG93cyBiYXNpYyBuZWdvdGlhdGlvbiBvZiBjYXBhYmlsaXRpZXMgYW5kIHRo ZSBhYmlsaXR5IHRvIGRvDQpzb21ldGhpbmcgdXNlZnVsIHdpdGggdGhlIGNhcGFiaWxpdHkuDQoN CjIpIEl0IGRvZXNuJ3QgcmVxdWlyZSBhbm90aGVyIElBTkEgcmVnaXN0cnkNCg0KMykgSXQgYnVp bGRzIG9uIGV4aXN0aW5nIGNvcmUgRExFUCBmdW5jdGlvbmFsaXR5IHRoYXQgTVVTVCBiZSBzdXBw b3J0ZWQNCmFscmVhZHkuDQoNCjQpIEl0IHJlcXVpcmVzIGEgKHNob3J0KSBkb2N1bWVudCBkZXNj cmliaW5nIGV4YWN0bHkgd2hhdCBlYWNoDQpjYXBhYmlsaXR5IG1lYW5zLCBhbmQgaG93IHRvIGhh bmRsZSBpdC4NCg0KRG93bnNpZGVzIGNvdWxkIGluY2x1ZGUgYSBjb25zdW1pbmcgZXh0ZW5zaW9u IG51bWJlciBzcGFjZS4NCg0KVGhvdWdodHM/DQoNClJpY2s= From nobody Fri Sep 8 04:09:21 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03F413239C for ; Fri, 8 Sep 2017 04:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6QUsxMhS3hnA for ; Fri, 8 Sep 2017 04:09:18 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68061132396 for ; Fri, 8 Sep 2017 04:09:18 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id z143so5400395qkb.3 for ; Fri, 08 Sep 2017 04:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sPPQHhalXY64LGt6cMdVGBhEpLQq9Zvh0tB+y9lR7KA=; b=IhGQYUHFjl8MxYYHiC4ehUUaisUpGH4/OXPrSQWSEE+/bIO/ybRLz6Wrn4fbc5M1dA a5mvFGdxW0X6pzx2N8ujJo4Sk2yw6t1IAARmGAScVuKLp8emX73bw99uxUmg5BOOE6kJ xQVjkLCXNWKVrr2zkN9HaOJrx1+QDih1fB9zE+ssRQIOwrx5QMIYJjye8OiNjJPRZNOR sATB+0r1Au98ASjUjjzfa5NKtRLoSEBBaM56RPwGXPJOMXkJ4SgXPtCEHuhjLDdKkvKd sYNupmCewcVVhlpQRTkwcx48sm2BzJGcY37ku20z9683wHiGi78SitU1pqvlCF53JcHU Wm4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sPPQHhalXY64LGt6cMdVGBhEpLQq9Zvh0tB+y9lR7KA=; b=l4x4Ny5PIfjATBUMPlKsEpLDPjwEFj6APM8TZ+CCpT8zXtaeCqc5iJiks7pnKEkaVf QG3sV96+/a0OzD36ZK9+tRy8msXVuPc5sTi5m4nrrfWMdSzeiYoToPwFyusD78AkQZio Ids9tz0+CNcJsDdSS/3ZJ9Tr/4F12EvIyVVWWyPQy2q0fMMaGuqWimn/hCD6T5fL5EjB 4DzIPHGw+73rV5ZdTQDBjlu+A6El3ZvfLezqbzyrWmHwdQmnZJKQ1VMLmbGnDxji9Rsb RSygebDDgzwQKgeWGnaqrKNclCDnBRDD+vfPy1ZHN60zZCe002kZVpeG1b56pZ1yT/8F T12w== X-Gm-Message-State: AHPjjUgjPgBslkhazy3fk11T6I3z/7NWDJpfuOPe0xrpVyCsXxRf6/ep 0gmPhCxJwZ7BHXLW1ZGKep6K/fOViC+tOdSjZ7s6AA== X-Google-Smtp-Source: AOwi7QDLR9l9m4DvhF9rDS+UGDaGUlgC/mRUF2iFxxsRudK5sJ+VNic1ysBMZ2FYOj0oWfkeWt3exOOLAoFfgFLaocE= X-Received: by 10.55.161.216 with SMTP id k207mr3055241qke.108.1504868957497; Fri, 08 Sep 2017 04:09:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.43.135 with HTTP; Fri, 8 Sep 2017 04:08:46 -0700 (PDT) In-Reply-To: <1504865375.15735.17.camel@tropicalstormsoftware.com> References: <1504865375.15735.17.camel@tropicalstormsoftware.com> From: Henning Rogge Date: Fri, 8 Sep 2017 13:08:46 +0200 Message-ID: To: Rick Taylor Cc: "manet@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [manet] DLEP extensions and capabilities X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 11:09:19 -0000 On Fri, Sep 8, 2017 at 12:09 PM, Rick Taylor wrote: > Hi All, > > I've been mulling over how one might implement an extension that allows > a DLEP peer to advertise its capabilities, as desired by Stan and > Henning. I'll stick to local capabilities for now, to scope the > problem a little. Good idea... lets stick to RADIO/interface specific local capabilities first... there might also be neighbor specific capabilities, but lets delay this discussion. > So, an obvious way to do this would be to create an Extension 'Local > Caps'. This extension would define a new Data Item, that lists the > capabilities, each defined by a number in a new IANA registry. This > Data Item is used during Session Init to announce capability. > > However, this looks remarkably like the extension mechanism itself. > Would it perhaps be more sensible to register device capabilities as > extensions in their own right, i.e. in the IANA DLEP Extension > Registry. So a modem that supports 'on-demand' data rates, would > advertise an 'On demand' extension, and a router that can do something > sensible with 'On demand' data rates also advertises support. If the > modem detects that it's talking to a router that doesn't understand > 'On-demand' then it could announce an artifical data rate as CDR > instead of 0. This feels a little bit as a dirty trick... especially because it needs to circumvent the "supported by both sides" mechanism of the DLEP protocol because we are using the extensions differently. If there is a "need unicast to determine MCS" attribute/capability of the radio, it makes no sense for the router to announce it... the normal mechanism for extensions would say "don't use it, router did not report it". Henning From nobody Fri Sep 8 08:04:15 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66849132932 for ; Fri, 8 Sep 2017 08:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NXH0-4RPpR_A for ; Fri, 8 Sep 2017 08:04:10 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32ED13292E for ; Fri, 8 Sep 2017 08:04:10 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id f199so3551967ita.1 for ; Fri, 08 Sep 2017 08:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=71ZlbZY6bbo19DOyx45Iz+WZzBprZqoCzuyieImel9w=; b=L6QA6X0YHlojARPQrTff+tCkOJXjALmInXwN5W3qCf0hDy01XWMKw90T5wY7XMrtD8 eMqNWjbIB55pdj1+RTM/rboxUIL+THAl2F9nzDzhalQjG5RWJXR8Uqq+mNztWE4t5SHs dS2FHN8hfiHPPLOgUGXkWf1YvGge5yedQ30EPcFflX4gnoyewe8G+M5Z4zTesSIjz8K0 k/FLq6J9Wzpz7kyC71xJY7OmTZOFwsNlh+4wQBNCN0gk0rQ5O7u7VgRipYQz74HyqPWI T2Z5gWHUxb94vz/EHv2KYF7PRW3QrakgonWMfSgXdILRYj/qKvXGw5LggmxZvS+YVbG6 in6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=71ZlbZY6bbo19DOyx45Iz+WZzBprZqoCzuyieImel9w=; b=Zs/6I274lbSvBwjPXW8H0eBIvHhzSV5g1znaBSzCTE0BmKxfc8PyVW1TBT0nZgYC0E OO9C9lXb8ph13BVNRGkR19O9L9ssPyWvJvlR8nmw5JymT9shoaCriS5H15BHqR/uQe6h xRWIhUT53B/dryTn+30xdMdMW94jf0Va52eXabK320RlfNB42OBQOK65ms9k4tm8SdhK ksXg5suXeZga4TAgtsWc6UcvbU43d6FxKMce2yX7pkL5uCgtYaYYQH0n7m/k4nx4r5x3 pBQjB4pwC5M5mFE8chcMXXx0/4NwW2+MZYms+xQ4cnhXFzCxMj0WZzNeFv+lJSsnmgiD yNOw== X-Gm-Message-State: AHPjjUgNp/hCjA0hGCUe7rQIXvFVusRbfvxE+0++HKmywkaKcMY86hhg pOjhhqd4WhWKcibfRewmzYoq/Mumow== X-Google-Smtp-Source: ADKCNb4TUL/ZqTUXahPSdKXlXbLXcdqINAgJ15KXjoJE4QDVS+9djo1eTOnm/UEC85XKVCKuvVO9XEqshH7ryZ0mgAk= X-Received: by 10.36.193.6 with SMTP id e6mr1347403itg.143.1504883049911; Fri, 08 Sep 2017 08:04:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.124.138 with HTTP; Fri, 8 Sep 2017 08:04:09 -0700 (PDT) In-Reply-To: <1504864640.15735.14.camel@tropicalstormsoftware.com> References: <1504863243.15735.13.camel@tropicalstormsoftware.com> <1504864640.15735.14.camel@tropicalstormsoftware.com> From: Stan Ratliff Date: Fri, 8 Sep 2017 11:04:09 -0400 Message-ID: To: Rick Taylor Cc: "hrogge@gmail.com" , "manet@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c07e8409e59460558aee320" Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 15:04:13 -0000 --94eb2c07e8409e59460558aee320 Content-Type: text/plain; charset="UTF-8" Hi everyone, Some thoughts/observations inline. Some of these are "devil's advocate" kind of responses, so please - don't throw your beer at me. ;-) Besides, beer is expensive! On Fri, Sep 8, 2017 at 5:57 AM, Rick Taylor wrote: > On Fri, 2017-09-08 at 11:39 +0200, Henning Rogge wrote: > > On Fri, Sep 8, 2017 at 11:34 AM, Rick Taylor > > wrote: > > > Hi Henning, > > > > > > The LID draft is actually an amalgamation of a 2 rough drafts I was > > > working on to solve two different use-cases, and Stan correctly > > > pointed > > > out the solution was the same: > > > > > > 1) There is some backhaul network accessible via a radio, where the > > > upstream router does not really exist in DLEP terms, it certainly > > > doesn't have a reachable MAC, and won't perform any kind of routing > > > protocol peering. But, there is definitely a link that can come > > > and > > > go, and metrics about the link are valid. An example could be > > > 3G. A > > > DLEP destination exists, it has routes and addresses, but no MAC. > > > > > > 2) Existing radio systems that mesh at layer-3. These radio > > > systems > > > can also supply valid DLEP information, but again, there are no MAC > > > addresses that make any sense. (This was the old Layer-3 DLEP > > > extension) > > > > > > I tried for some time to keep the DLEP MAC address Data Item as the > > > 'primary key', initially by having an extra data item: "This MAC is > > > not > > > a MAC", but the end result is the same. To support LIDs, somewhere > > > in > > > your DLEP information base you need a field associated with your > > > Destination that specifies whether the ID is a MAC or not. > > > > > > After extensive discussion with Stan and Keith Morgan (on list > > > 31/5/17 > > > onwards), I was convinced that a separate Data Item, replacing the > > > MAC, > > > but of the same byte-length as the MAC was the most elegant > > > solution. > > > But I'm not fixed in my opinion, if the WG wants to adopt this > > > extension, and the consensus is that an extra "Not-MAC" data item > > > is > > > the better way to go, then so be it. > > > > > > So in conclusion, the LID extension proposes loosening the > > > definition > > > of the 'primary key' for your Destinations from 'They are Layer-2 > > > addresses/MACs' to 'They are fixed length identifiers, some of > > > which > > > are MACs'. And the extension defines how a peer can differentiate > > > between them. > > > > In fact we do something similar here, "inventing" a (non-global) MAC > > for transmitting metrics for IP destinations. > > It seems to be the common work-around. > > > > > As I said in the other mail, I am just a bit worried about removing a > > mandatory TLV from a message. > > And that could be a good reason for having the 'Not-MAC' data item > instead... > > And I think the "Not-MAC" data item presents its own opportunity for confusion, since the mandatory data item is a MAC. So, it's a MAC. Unless it isn't. That's consistent... ;-) Seems to me that there are two issues to be solved. The first is how to signal to a router that this destination is somehow "special". In this case, "special" = Rick's original point 1 above (no real DLEP peer, no reachable MAC, but a path to a prefix or set of prefixes). The second problem is how to tell the router to format L2 frames headed to that "special" destination. In this case, the router should use the *radio's MAC* as the D-MAC in frames wanting to go up the "special" link. I think the existing LID draft covers both of the problems, although (IIRC) the D-MAC for data packets is more inferred than signaled. But it does occur to me: We *could* signal this by using the MAC address *of the radio itself*, followed by the LID TLV. That explicitly signals both the MAC address to use on the data path, and the fact that this destination is "special". Multiple LID indicators could be placed on the Destination Up, indicating that the modem has more than 1 "special" pipe, but in all cases, the router should use the signaled MAC for traffic to those pipes. Signaling multiple LIDs on a single Destination Up might have some drawbacks, in that I don't readily see (without the use of container TLVs) how to provide LID-specific initial metrics on Dest Up, and the same issue exists with Destination Update to signal metric changes for a specific LID (again, employ the container TLV concept?). One way (possibly seen as "klunky") to handle metrics, adding, and deleting is to consider (for purposes of the extension) the MAC/LID as a tuple - each MAC/LID combination is a separate DLEP Destination, and the requirement for things to be unique extends to the tuple in this case. The radio could ONLY specify 1 MAC/LID tuple per Destination Up/Destination Update/Destination Down. There are downsides there : 1. If the modem has 256 of these "special" links, then it'll take 256 Destination Up messages to get them all up & ready to go. 2. It's obviously tougher to parse - you can't just pick up a MAC address and search internal structures to see if you already have this Destination. There are probably other down-sides I'm not thinking of. But on the up-side, it allows us to use the existing Destination Update (which would also carry the MAC/LID tuple) for providing metrics on a single LID, and adding or deleting prefixes for said LID. And, at least in this case, a MAC is always a MAC... ;-) Just a thought. Regards, Stan --94eb2c07e8409e59460558aee320 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,=C2=A0

Some thoughts/observ= ations inline. Some of these are "devil's advocate" kind of r= esponses, so please - don't throw your beer at me. ;-) Besides, beer is= expensive!

= On Fri, Sep 8, 2017 at 5:57 AM, Rick Taylor <rick@tropicals= tormsoftware.com> wrote:
On= Fri, 2017-09-08 at 11:39 +0200, Henning Rogge wrote:
> On Fri, Sep 8, 2017 at 11:34 AM, Rick Taylor
> <rick@tropicalsto= rmsoftware.com> wrote:
> > Hi Henning,
> >
> > The LID draft is actually an amalgamation of a 2 rough drafts I w= as
> > working on to solve two different use-cases, and Stan correctly > > pointed
> > =C2=A0out the solution was the same:
> >
> > 1) There is some backhaul network accessible via a radio, where t= he
> > upstream router does not really exist in DLEP terms, it certainly=
> > doesn't have a reachable MAC, and won't perform any kind = of routing
> > protocol peering.=C2=A0=C2=A0But, there is definitely a link that= can come
> > and
> > go, and metrics about the link are valid.=C2=A0=C2=A0An example c= ould be
> > 3G.=C2=A0=C2=A0A
> > DLEP destination exists, it has routes and addresses, but no MAC.=
> >
> > 2) Existing radio systems that mesh at layer-3.=C2=A0=C2=A0These = radio
> > systems
> > can also supply valid DLEP information, but again, there are no M= AC
> > addresses that make any sense. (This was the old Layer-3 DLEP
> > extension)
> >
> > I tried for some time to keep the DLEP MAC address Data Item as t= he
> > 'primary key', initially by having an extra data item: &q= uot;This MAC is
> > not
> > a MAC", but the end result is the same.=C2=A0=C2=A0To suppor= t LIDs, somewhere
> > in
> > your DLEP information base you need a field associated with your<= br> > > Destination that specifies whether the ID is a MAC or not.
> >
> > After extensive discussion with Stan and Keith Morgan (on list > > 31/5/17
> > onwards), I was convinced that a separate Data Item, replacing th= e
> > MAC,
> > but of the same byte-length as the MAC was the most elegant
> > solution.
> > But I'm not fixed in my opinion,=C2=A0=C2=A0if the WG wants t= o adopt this
> > extension, and the consensus is that an extra "Not-MAC"= data item
> > is
> > the better way to go, then so be it.
> >
> > So in conclusion, the LID extension proposes loosening the
> > definition
> > of the 'primary key' for your Destinations from 'They= are Layer-2
> > addresses/MACs' to 'They are fixed length identifiers, so= me of
> > which
> > are MACs'.=C2=A0=C2=A0And the extension defines how a peer ca= n differentiate
> > between them.
>
> In fact we do something similar here, "inventing" a (non-glo= bal) MAC
> for transmitting metrics for IP destinations.

It seems to be the common work-around.

>
> As I said in the other mail, I am just a bit worried about removing a<= br> > mandatory TLV from a message.

And that could be a good reason for having the 'Not-MAC' data item<= br> instead...

=C2=A0
And I think the "= Not-MAC" data item presents its own opportunity for confusion, since t= he mandatory data item is a MAC. So, it's a MAC. Unless it isn't. T= hat's consistent... ;-)=C2=A0

Seems to me that= there are two issues to be solved. The first is how to signal to a router = that this destination is somehow "special". In this case, "s= pecial" =3D Rick's original point 1 above (no real DLEP peer, no r= eachable MAC, but a path to a prefix or set of prefixes).

The second problem is how to tell the router to format L2 frames he= aded to that "special" destination. In this case, the router shou= ld use the *radio's MAC* as the D-MAC in frames wanting to go up the &q= uot;special" link.=C2=A0

I think the existing LID draft covers both of the problems, although (II= RC) the D-MAC for data packets is more inferred than signaled.=C2=A0
<= div class=3D"gmail_extra">
But it does = occur to me: =C2=A0We *could* signal this by using the MAC address *of the = radio itself*, followed by the LID TLV. That explicitly signals both the MA= C address to use on the data path, and the fact that this destination is &q= uot;special". Multiple LID indicators could be placed on the Destinati= on Up, indicating that the modem has more than 1 "special" pipe, = but in all cases, the router should use the signaled MAC for traffic to tho= se pipes.

Signaling multiple LIDs on a single Destination Up might have some draw= backs, in that I don't readily see (without the use of container TLVs) = how to provide LID-specific initial metrics on Dest Up, and the same issue = exists with Destination Update to signal metric changes for a specific LID = (again, employ the container TLV concept?).

One way (possibly seen as "klunk= y") to handle metrics, adding, and deleting is to consider (for purpos= es of the extension) the MAC/LID as a tuple - each MAC/LID combination is a= separate DLEP Destination, and the requirement for things to be unique ext= ends to the tuple in this case. The radio could ONLY specify 1 MAC/LID tupl= e per Destination Up/Destination Update/Destination Down. There are downsid= es there :
1. If the modem has 256 of these= "special" links, then it'll take 256 Destination Up messages= to get them all up & ready to go.=C2=A0
2. It's obviously tougher to parse - you can't just pick up a MAC= address and search internal structures to see if you already have this Des= tination.=C2=A0
There are probably other do= wn-sides I'm not thinking of.=C2=A0
But on the up-side, it allows us to use t= he existing Destination Update (which would also carry the MAC/LID tuple) f= or providing metrics on a single LID, and adding or deleting prefixes for s= aid LID.=C2=A0

And, at least in this case, a MAC is always a MAC... ;-)=C2=A0

Just a th= ought.=C2=A0

Regards,
Stan
--94eb2c07e8409e59460558aee320-- From nobody Mon Sep 11 00:53:53 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB74132D4A for ; Mon, 11 Sep 2017 00:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Fro6Kevv2ooW for ; Mon, 11 Sep 2017 00:53:49 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9637C1321A7 for ; Mon, 11 Sep 2017 00:53:49 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id b82so16927385qkc.4 for ; Mon, 11 Sep 2017 00:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Dmcr+92QYlYHQe4uqVRehydizJKsgvzOY2pSF7tB0IM=; b=bw2ZZHIxuxcCorvEoeYQZtOvH9+RnF4HaPetZycKURXTmpyMje5TbUquDVJrOz0IUR Q3U0cPYSbzjtNQ5PsifHk+7yhbegoe88S7W6tOzNoRvd9i5XJAlSDSQt5mTydwZGEnnw C8jkBc+BAUbUzJ1TahgW0qlZvRREIGwSqs2ShbSd0fmaSxdCQ4QbCL/CRY34Ks4jX6sP gonG3T5/879k5ieM5fOfPN9cDCXIGG16IfLxj6TeOO/2+Kd035Gb9Fghlz8wVaCncvv2 HS2pSYsvIvVt5u+LO92xbfDY3p2FGxqETHXAsm1JgEFoDQh7B5zdLeILzh5zh9/KmV4U tkSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Dmcr+92QYlYHQe4uqVRehydizJKsgvzOY2pSF7tB0IM=; b=MhXf6JZQsX/xBs/sIX2jzGImDGHw7ZnYsekC+GhQBYeBQ+Mt7prqkmqJZ5thCIfkP8 hm1g9Lnxxfmh7mXoA18j2EQmuqcJhvMyO/rydv2KCEDft9jQ2cIq5WznLdoceR5LRpcU Vdwp1rKUPcgmeX923SMBzzOY0kRlQxY6TXaNhzoELwGRpAB8QvVqCLwqoMBSV+eKQIdt P/VI7LiCMUkhpAM2g9Ez4+OJqzIOuawS53kY6/oH6X/la8BcX+UVQyAmv3xXHp2+crAR RUJRiF+O2f49mrrWlGeKk7g3eVJCe4Y+gHN+cQDrbE+qQt7bL36Nd3xwsaeXE8J8FhDI G+vw== X-Gm-Message-State: AHPjjUgVCJq0Bhx9EuLX0FFEVjUiUuraZa6k35NSNhj/DHSmCKep7AZE DcU/UZyBuaFtN96VxR3Jj7XYosBoekrTxnlnlmw= X-Google-Smtp-Source: AOwi7QAI91V/nsC0NlEWmYICYmQQIZY1kN8OQ1khtnugsD2fC9pvGl2iyYLnpy4TIyde7/4lbBAoty/jk704MHo9J1A= X-Received: by 10.233.239.69 with SMTP id d66mr13982818qkg.296.1505116428532; Mon, 11 Sep 2017 00:53:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.50.229 with HTTP; Mon, 11 Sep 2017 00:53:17 -0700 (PDT) In-Reply-To: References: <1504863243.15735.13.camel@tropicalstormsoftware.com> <1504864640.15735.14.camel@tropicalstormsoftware.com> From: Henning Rogge Date: Mon, 11 Sep 2017 09:53:17 +0200 Message-ID: To: Stan Ratliff Cc: Rick Taylor , "manet@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 07:53:51 -0000 Hi, lets get the ball rolling again after the weekend... all this "MAC is not a MAC" thing got me thinking if we are trying to hard to keep the original identifier. I am not sure I like Stan's suggestion using the radio as "destination" for all "multiple IP hops away" targets, but it could work and it makes sense in terms of "this is the MAC you have to send data to". You could use the MAC reported from DLEP to fill the ARP table. But maybe we should rethink making the LID 6 bytes just as the MAC... IF we put it into a TLV of its own (as Rick suggested), maybe extending the length to 128 bits would be better... this way we can put things like an UUID into it and we have less confusion about MAC versus PC \r\r LID. What do you think? Henning On Fri, Sep 8, 2017 at 5:04 PM, Stan Ratliff wrote: > Hi everyone, > > Some thoughts/observations inline. Some of these are "devil's advocate" kind > of responses, so please - don't throw your beer at me. ;-) Besides, beer is > expensive! > > On Fri, Sep 8, 2017 at 5:57 AM, Rick Taylor > wrote: >> >> On Fri, 2017-09-08 at 11:39 +0200, Henning Rogge wrote: >> > On Fri, Sep 8, 2017 at 11:34 AM, Rick Taylor >> > wrote: >> > > Hi Henning, >> > > >> > > The LID draft is actually an amalgamation of a 2 rough drafts I was >> > > working on to solve two different use-cases, and Stan correctly >> > > pointed >> > > out the solution was the same: >> > > >> > > 1) There is some backhaul network accessible via a radio, where the >> > > upstream router does not really exist in DLEP terms, it certainly >> > > doesn't have a reachable MAC, and won't perform any kind of routing >> > > protocol peering. But, there is definitely a link that can come >> > > and >> > > go, and metrics about the link are valid. An example could be >> > > 3G. A >> > > DLEP destination exists, it has routes and addresses, but no MAC. >> > > >> > > 2) Existing radio systems that mesh at layer-3. These radio >> > > systems >> > > can also supply valid DLEP information, but again, there are no MAC >> > > addresses that make any sense. (This was the old Layer-3 DLEP >> > > extension) >> > > >> > > I tried for some time to keep the DLEP MAC address Data Item as the >> > > 'primary key', initially by having an extra data item: "This MAC is >> > > not >> > > a MAC", but the end result is the same. To support LIDs, somewhere >> > > in >> > > your DLEP information base you need a field associated with your >> > > Destination that specifies whether the ID is a MAC or not. >> > > >> > > After extensive discussion with Stan and Keith Morgan (on list >> > > 31/5/17 >> > > onwards), I was convinced that a separate Data Item, replacing the >> > > MAC, >> > > but of the same byte-length as the MAC was the most elegant >> > > solution. >> > > But I'm not fixed in my opinion, if the WG wants to adopt this >> > > extension, and the consensus is that an extra "Not-MAC" data item >> > > is >> > > the better way to go, then so be it. >> > > >> > > So in conclusion, the LID extension proposes loosening the >> > > definition >> > > of the 'primary key' for your Destinations from 'They are Layer-2 >> > > addresses/MACs' to 'They are fixed length identifiers, some of >> > > which >> > > are MACs'. And the extension defines how a peer can differentiate >> > > between them. >> > >> > In fact we do something similar here, "inventing" a (non-global) MAC >> > for transmitting metrics for IP destinations. >> >> It seems to be the common work-around. >> >> > >> > As I said in the other mail, I am just a bit worried about removing a >> > mandatory TLV from a message. >> >> And that could be a good reason for having the 'Not-MAC' data item >> instead... >> > > And I think the "Not-MAC" data item presents its own opportunity for > confusion, since the mandatory data item is a MAC. So, it's a MAC. Unless it > isn't. That's consistent... ;-) > > Seems to me that there are two issues to be solved. The first is how to > signal to a router that this destination is somehow "special". In this case, > "special" = Rick's original point 1 above (no real DLEP peer, no reachable > MAC, but a path to a prefix or set of prefixes). > > The second problem is how to tell the router to format L2 frames headed to > that "special" destination. In this case, the router should use the *radio's > MAC* as the D-MAC in frames wanting to go up the "special" link. > > I think the existing LID draft covers both of the problems, although (IIRC) > the D-MAC for data packets is more inferred than signaled. > > But it does occur to me: We *could* signal this by using the MAC address > *of the radio itself*, followed by the LID TLV. That explicitly signals both > the MAC address to use on the data path, and the fact that this destination > is "special". Multiple LID indicators could be placed on the Destination Up, > indicating that the modem has more than 1 "special" pipe, but in all cases, > the router should use the signaled MAC for traffic to those pipes. > > Signaling multiple LIDs on a single Destination Up might have some > drawbacks, in that I don't readily see (without the use of container TLVs) > how to provide LID-specific initial metrics on Dest Up, and the same issue > exists with Destination Update to signal metric changes for a specific LID > (again, employ the container TLV concept?). > > One way (possibly seen as "klunky") to handle metrics, adding, and deleting > is to consider (for purposes of the extension) the MAC/LID as a tuple - each > MAC/LID combination is a separate DLEP Destination, and the requirement for > things to be unique extends to the tuple in this case. The radio could ONLY > specify 1 MAC/LID tuple per Destination Up/Destination Update/Destination > Down. There are downsides there : > 1. If the modem has 256 of these "special" links, then it'll take 256 > Destination Up messages to get them all up & ready to go. > 2. It's obviously tougher to parse - you can't just pick up a MAC address > and search internal structures to see if you already have this Destination. > There are probably other down-sides I'm not thinking of. > > But on the up-side, it allows us to use the existing Destination Update > (which would also carry the MAC/LID tuple) for providing metrics on a single > LID, and adding or deleting prefixes for said LID. > > And, at least in this case, a MAC is always a MAC... ;-) > > Just a thought. > > Regards, > Stan From nobody Mon Sep 11 07:44:37 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DA0132D54 for ; Mon, 11 Sep 2017 07:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DfZCSrB_M5nB for ; Mon, 11 Sep 2017 07:44:32 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9B11321B6 for ; Mon, 11 Sep 2017 07:44:32 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id o200so19380507itg.0 for ; Mon, 11 Sep 2017 07:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=PJ6cj+iS+/NULIL0NZsLpyMH9qclmmvdPjJCJLWftS4=; b=bxeufX0shLJKH+2qxDGa759vj7YaXwgeRurvxSxVy4wEXwxQZoI6+VwbAE9EB57tnv B9YzH2l9Zt+qKLGoBtT/LDoPA4wO/erUi4wmabyRWiD1fglaMYTxbiSEphulMicMidDT IMHY70XLA2KfmVuKCymwMJWK0BH+O4QKGwPeRLSWhFaJ5zGWzoZUZ9WZBEp1GciGw5A0 1/RTIo8YNgJy8L4a/zQohXMniIa8pJFXbkSJNNrDujKr4hJlABZszL7KL9nFnssgkfaM OCyalGrG6aikJLFoiwY+/0iH+UdSKqPSNVUoR6yFcuq2OsPWPlZzOCkUuEkEn32ZPTpm jJDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=PJ6cj+iS+/NULIL0NZsLpyMH9qclmmvdPjJCJLWftS4=; b=ekj9a0yxlSAbnze1W9DCAACD3AQlmn/hBTd68dYjahA6OM4yEox3feBVbdF3x6eAqX 3++ZyzTPUwy1y/+RQjQP5R6YqDlXSo052Vc4Ksp8PEDhxXB/tzbfqnAMjH1j0TLY+O0y XWZ4jBqEy05CcAYk75NbmNhu2x/6Wh/5ZzX5n4v+3jJVlxO5F3gf+vHmuy+2jTLf2pdd 11TMxn3mByuBXNV2RsnFKY4x369IgIg6QrSIpg/wwF/MkKWGtOu1AbTPmQVNWkARw4OV M4fsAZDxHuZmyv2RQw6P34Mfh/5Zvp/kjpvm95gOPkvUS1XP1I4JxYH1CRMba5E7wovW kMfA== X-Gm-Message-State: AHPjjUjkI4y87XhNTz1OHD0ztUeW90N7mfyIzR//LKOsqQn+hRuLogCc QMKq17EToYQvj3df282mip/cbIpxZQ== X-Google-Smtp-Source: AOwi7QAPGtQld6wITPDVMXCJw1ol+Dz+yiJvk/aszn6XAkPPNkJ7Cyww64th63psvFuogMBPKlNk17nidy00Lt67Dnc= X-Received: by 10.36.20.86 with SMTP id 83mr14416128itg.44.1505141071888; Mon, 11 Sep 2017 07:44:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.124.138 with HTTP; Mon, 11 Sep 2017 07:44:31 -0700 (PDT) In-Reply-To: References: <1504863243.15735.13.camel@tropicalstormsoftware.com> <1504864640.15735.14.camel@tropicalstormsoftware.com> From: Stan Ratliff Date: Mon, 11 Sep 2017 10:44:31 -0400 Message-ID: To: Henning Rogge , Rick Taylor , MANET IETF Content-Type: multipart/alternative; boundary="001a1143e748ed60730558eaf65c" Archived-At: Subject: [manet] Fwd: Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 14:44:36 -0000 --001a1143e748ed60730558eaf65c Content-Type: text/plain; charset="UTF-8" Apologies, I responded directly to Henning with this. Adding Rick + MANET list. Regards, Stan ---------- Forwarded message ---------- From: Stan Ratliff Date: Mon, Sep 11, 2017 at 10:42 AM Subject: Re: [manet] Thoughts on draft-dlep-lid To: Henning Rogge A couple of thoughts inline: On Mon, Sep 11, 2017 at 3:53 AM, Henning Rogge wrote: > Hi, > > lets get the ball rolling again after the weekend... all this "MAC is > not a MAC" thing got me thinking if we are trying to hard to keep the > original identifier. > > I am not sure I like Stan's suggestion using the radio as > "destination" for all "multiple IP hops away" targets, but it could > work and it makes sense in terms of "this is the MAC you have to send > data to". You could use the MAC reported from DLEP to fill the ARP > table. > As I understand the rationale behind the LID extension, it assumes that there's L3 forwarding occurring on the non-DLEP links. That being the case, if you want the radio to forward traffic in this fashion, you have to send said traffic to the radio's MAC. The radio is, by definition, the router's next hop. IIRC, the current LID draft assumes the router already has the radio's MAC, since the router is in a DLEP/TCP session with the radio. Because of that, I'll admit that my suggestion is a bit redundant, in that the radio sends information the router already has. But this flow makes the LIDs fit in to the parsing scheme easier (at least IMO, it's easier), and it's explicit as to where the router must send the traffic at L2. > > But maybe we should rethink making the LID 6 bytes just as the MAC... > IF we put it into a TLV of its own (as Rick suggested), maybe > extending the length to 128 bits would be better... this way we can > put things like an UUID into it and we have less confusion about MAC > versus PC \r\r LID. > Again, IIRC, some of the initial discussions on-list talked about a LID length that was variable. That is something I'm opposed to, as it makes searching them less efficient. The main thing I like about the notion that sizeof(LID) == sizeof(MAC) is that I can put them in the same searchable data structure (in my case, an AVL tree), as long as they don't clash. I can live with sizeof(LID) != sizeof(MAC), but I think that's sub-optimal. What I see as really bad is the notion of a variable length LID. Regards, Stan > > What do you think? > > Henning > > On Fri, Sep 8, 2017 at 5:04 PM, Stan Ratliff > wrote: > > Hi everyone, > > > > Some thoughts/observations inline. Some of these are "devil's advocate" > kind > > of responses, so please - don't throw your beer at me. ;-) Besides, beer > is > > expensive! > > > > On Fri, Sep 8, 2017 at 5:57 AM, Rick Taylor < > rick@tropicalstormsoftware.com> > > wrote: > >> > >> On Fri, 2017-09-08 at 11:39 +0200, Henning Rogge wrote: > >> > On Fri, Sep 8, 2017 at 11:34 AM, Rick Taylor > >> > wrote: > >> > > Hi Henning, > >> > > > >> > > The LID draft is actually an amalgamation of a 2 rough drafts I was > >> > > working on to solve two different use-cases, and Stan correctly > >> > > pointed > >> > > out the solution was the same: > >> > > > >> > > 1) There is some backhaul network accessible via a radio, where the > >> > > upstream router does not really exist in DLEP terms, it certainly > >> > > doesn't have a reachable MAC, and won't perform any kind of routing > >> > > protocol peering. But, there is definitely a link that can come > >> > > and > >> > > go, and metrics about the link are valid. An example could be > >> > > 3G. A > >> > > DLEP destination exists, it has routes and addresses, but no MAC. > >> > > > >> > > 2) Existing radio systems that mesh at layer-3. These radio > >> > > systems > >> > > can also supply valid DLEP information, but again, there are no MAC > >> > > addresses that make any sense. (This was the old Layer-3 DLEP > >> > > extension) > >> > > > >> > > I tried for some time to keep the DLEP MAC address Data Item as the > >> > > 'primary key', initially by having an extra data item: "This MAC is > >> > > not > >> > > a MAC", but the end result is the same. To support LIDs, somewhere > >> > > in > >> > > your DLEP information base you need a field associated with your > >> > > Destination that specifies whether the ID is a MAC or not. > >> > > > >> > > After extensive discussion with Stan and Keith Morgan (on list > >> > > 31/5/17 > >> > > onwards), I was convinced that a separate Data Item, replacing the > >> > > MAC, > >> > > but of the same byte-length as the MAC was the most elegant > >> > > solution. > >> > > But I'm not fixed in my opinion, if the WG wants to adopt this > >> > > extension, and the consensus is that an extra "Not-MAC" data item > >> > > is > >> > > the better way to go, then so be it. > >> > > > >> > > So in conclusion, the LID extension proposes loosening the > >> > > definition > >> > > of the 'primary key' for your Destinations from 'They are Layer-2 > >> > > addresses/MACs' to 'They are fixed length identifiers, some of > >> > > which > >> > > are MACs'. And the extension defines how a peer can differentiate > >> > > between them. > >> > > >> > In fact we do something similar here, "inventing" a (non-global) MAC > >> > for transmitting metrics for IP destinations. > >> > >> It seems to be the common work-around. > >> > >> > > >> > As I said in the other mail, I am just a bit worried about removing a > >> > mandatory TLV from a message. > >> > >> And that could be a good reason for having the 'Not-MAC' data item > >> instead... > >> > > > > And I think the "Not-MAC" data item presents its own opportunity for > > confusion, since the mandatory data item is a MAC. So, it's a MAC. > Unless it > > isn't. That's consistent... ;-) > > > > Seems to me that there are two issues to be solved. The first is how to > > signal to a router that this destination is somehow "special". In this > case, > > "special" = Rick's original point 1 above (no real DLEP peer, no > reachable > > MAC, but a path to a prefix or set of prefixes). > > > > The second problem is how to tell the router to format L2 frames headed > to > > that "special" destination. In this case, the router should use the > *radio's > > MAC* as the D-MAC in frames wanting to go up the "special" link. > > > > I think the existing LID draft covers both of the problems, although > (IIRC) > > the D-MAC for data packets is more inferred than signaled. > > > > But it does occur to me: We *could* signal this by using the MAC address > > *of the radio itself*, followed by the LID TLV. That explicitly signals > both > > the MAC address to use on the data path, and the fact that this > destination > > is "special". Multiple LID indicators could be placed on the Destination > Up, > > indicating that the modem has more than 1 "special" pipe, but in all > cases, > > the router should use the signaled MAC for traffic to those pipes. > > > > Signaling multiple LIDs on a single Destination Up might have some > > drawbacks, in that I don't readily see (without the use of container > TLVs) > > how to provide LID-specific initial metrics on Dest Up, and the same > issue > > exists with Destination Update to signal metric changes for a specific > LID > > (again, employ the container TLV concept?). > > > > One way (possibly seen as "klunky") to handle metrics, adding, and > deleting > > is to consider (for purposes of the extension) the MAC/LID as a tuple - > each > > MAC/LID combination is a separate DLEP Destination, and the requirement > for > > things to be unique extends to the tuple in this case. The radio could > ONLY > > specify 1 MAC/LID tuple per Destination Up/Destination Update/Destination > > Down. There are downsides there : > > 1. If the modem has 256 of these "special" links, then it'll take 256 > > Destination Up messages to get them all up & ready to go. > > 2. It's obviously tougher to parse - you can't just pick up a MAC address > > and search internal structures to see if you already have this > Destination. > > There are probably other down-sides I'm not thinking of. > > > > But on the up-side, it allows us to use the existing Destination Update > > (which would also carry the MAC/LID tuple) for providing metrics on a > single > > LID, and adding or deleting prefixes for said LID. > > > > And, at least in this case, a MAC is always a MAC... ;-) > > > > Just a thought. > > > > Regards, > > Stan > --001a1143e748ed60730558eaf65c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies, I responded directly to Henning with this. Addi= ng Rick + MANET list.=C2=A0

Regards,
Stan

---------- Forwarded message ---------= -
From: Stan Ratliff <ratliffstan@gmail.com>=
Date: Mon, Sep 11, 2017 at 10:42 AM
Subject: Re: [manet] Thou= ghts on draft-dlep-lid
To: Henning Rogge <hrogge@gmail.com>


A couple of t= houghts inline:

On Mon, Sep 11, 2017 at 3:53 AM, Henning Rogge <hrogge@gmail.com><= /span> wrote:
Hi,

lets get the ball rolling again after the weekend... all this "MAC is<= br> not a MAC" thing got me thinking if we are trying to hard to keep the<= br> original identifier.

I am not sure I like Stan's suggestion using the radio as
"destination" for all "multiple IP hops away" targets, = but it could
work and it makes sense in terms of "this is the MAC you have to send<= br> data to". You could use the MAC reported from DLEP to fill the ARP
table.

As I understand the rationale be= hind the LID extension, it assumes that there's L3 forwarding occurring= on the non-DLEP links. That being the case, if you want the radio to forwa= rd traffic in this fashion, you have to send said traffic to the radio'= s MAC. The radio is, by definition, the router's next hop.=C2=A0
<= div>
IIRC, the current LID draft assumes the router already h= as the radio's MAC, since the router is in a DLEP/TCP session with the = radio. Because of that, I'll admit that my suggestion is a bit redundan= t, in that the radio sends information the router already has. But this flo= w makes the LIDs fit in to the parsing scheme easier (at least IMO, it'= s easier), and it's explicit as to where the router must send the traff= ic at L2. =C2=A0=C2=A0
=C2=A0

But maybe we should rethink making the LID 6 bytes just as the MAC...
IF we put it into a TLV of its own (as Rick suggested), maybe
extending the length to 128 bits would be better... this way we can
put things like an UUID into it and we have less confusion about MAC
versus PC \r\r LID.

Again, IIRC, some o= f the initial discussions on-list talked about a LID length that was variab= le. That is something I'm opposed to, as it makes searching them less e= fficient. The main thing I like about the notion that sizeof(LID) =3D=3D si= zeof(MAC) is that I can put them in the same searchable data structure (in = my case, an AVL tree), as long as they don't clash. I can live with siz= eof(LID) !=3D sizeof(MAC), but I think that's sub-optimal. What I see a= s really bad is the notion of a variable length LID.=C2=A0

Regards,
Stan

=C2=A0

What do you think?

Henning

On Fri, Sep 8, 2017 at 5:04 PM, Stan Ratliff <ratliffstan@gmail.com> wrote:
> Hi everyone,
>
> Some thoughts/observations inline. Some of these are "devil's= advocate" kind
> of responses, so please - don't throw your beer at me. ;-) Besides= , beer is
> expensive!
>
> On Fri, Sep 8, 2017 at 5:57 AM, Rick Taylor <rick@tropicalstormsoftware.co= m>
> wrote:
>>
>> On Fri, 2017-09-08 at 11:39 +0200, Henning Rogge wrote:
>> > On Fri, Sep 8, 2017 at 11:34 AM, Rick Taylor
>> > <rick@tropicalstormsoftware.com> wrote:
>> > > Hi Henning,
>> > >
>> > > The LID draft is actually an amalgamation of a 2 rough d= rafts I was
>> > > working on to solve two different use-cases, and Stan co= rrectly
>> > > pointed
>> > >=C2=A0 out the solution was the same:
>> > >
>> > > 1) There is some backhaul network accessible via a radio= , where the
>> > > upstream router does not really exist in DLEP terms, it = certainly
>> > > doesn't have a reachable MAC, and won't perform = any kind of routing
>> > > protocol peering.=C2=A0 But, there is definitely a link = that can come
>> > > and
>> > > go, and metrics about the link are valid.=C2=A0 An examp= le could be
>> > > 3G.=C2=A0 A
>> > > DLEP destination exists, it has routes and addresses, bu= t no MAC.
>> > >
>> > > 2) Existing radio systems that mesh at layer-3.=C2=A0 Th= ese radio
>> > > systems
>> > > can also supply valid DLEP information, but again, there= are no MAC
>> > > addresses that make any sense. (This was the old Layer-3= DLEP
>> > > extension)
>> > >
>> > > I tried for some time to keep the DLEP MAC address Data = Item as the
>> > > 'primary key', initially by having an extra data= item: "This MAC is
>> > > not
>> > > a MAC", but the end result is the same.=C2=A0 To su= pport LIDs, somewhere
>> > > in
>> > > your DLEP information base you need a field associated w= ith your
>> > > Destination that specifies whether the ID is a MAC or no= t.
>> > >
>> > > After extensive discussion with Stan and Keith Morgan (o= n list
>> > > 31/5/17
>> > > onwards), I was convinced that a separate Data Item, rep= lacing the
>> > > MAC,
>> > > but of the same byte-length as the MAC was the most eleg= ant
>> > > solution.
>> > > But I'm not fixed in my opinion,=C2=A0 if the WG wan= ts to adopt this
>> > > extension, and the consensus is that an extra "Not-= MAC" data item
>> > > is
>> > > the better way to go, then so be it.
>> > >
>> > > So in conclusion, the LID extension proposes loosening t= he
>> > > definition
>> > > of the 'primary key' for your Destinations from = 'They are Layer-2
>> > > addresses/MACs' to 'They are fixed length identi= fiers, some of
>> > > which
>> > > are MACs'.=C2=A0 And the extension defines how a pee= r can differentiate
>> > > between them.
>> >
>> > In fact we do something similar here, "inventing" a= (non-global) MAC
>> > for transmitting metrics for IP destinations.
>>
>> It seems to be the common work-around.
>>
>> >
>> > As I said in the other mail, I am just a bit worried about re= moving a
>> > mandatory TLV from a message.
>>
>> And that could be a good reason for having the 'Not-MAC' d= ata item
>> instead...
>>
>
> And I think the "Not-MAC" data item presents its own opportu= nity for
> confusion, since the mandatory data item is a MAC. So, it's a MAC.= Unless it
> isn't. That's consistent... ;-)
>
> Seems to me that there are two issues to be solved. The first is how t= o
> signal to a router that this destination is somehow "special"= ;. In this case,
> "special" =3D Rick's original point 1 above (no real DLE= P peer, no reachable
> MAC, but a path to a prefix or set of prefixes).
>
> The second problem is how to tell the router to format L2 frames heade= d to
> that "special" destination. In this case, the router should = use the *radio's
> MAC* as the D-MAC in frames wanting to go up the "special" l= ink.
>
> I think the existing LID draft covers both of the problems, although (= IIRC)
> the D-MAC for data packets is more inferred than signaled.
>
> But it does occur to me:=C2=A0 We *could* signal this by using the MAC= address
> *of the radio itself*, followed by the LID TLV. That explicitly signal= s both
> the MAC address to use on the data path, and the fact that this destin= ation
> is "special". Multiple LID indicators could be placed on the= Destination Up,
> indicating that the modem has more than 1 "special" pipe, bu= t in all cases,
> the router should use the signaled MAC for traffic to those pipes.
>
> Signaling multiple LIDs on a single Destination Up might have some
> drawbacks, in that I don't readily see (without the use of contain= er TLVs)
> how to provide LID-specific initial metrics on Dest Up, and the same i= ssue
> exists with Destination Update to signal metric changes for a specific= LID
> (again, employ the container TLV concept?).
>
> One way (possibly seen as "klunky") to handle metrics, addin= g, and deleting
> is to consider (for purposes of the extension) the MAC/LID as a tuple = - each
> MAC/LID combination is a separate DLEP Destination, and the requiremen= t for
> things to be unique extends to the tuple in this case. The radio could= ONLY
> specify 1 MAC/LID tuple per Destination Up/Destination Update/Destinat= ion
> Down. There are downsides there :
> 1. If the modem has 256 of these "special" links, then it= 9;ll take 256
> Destination Up messages to get them all up & ready to go.
> 2. It's obviously tougher to parse - you can't just pick up a = MAC address
> and search internal structures to see if you already have this Destina= tion.
> There are probably other down-sides I'm not thinking of.
>
> But on the up-side, it allows us to use the existing Destination Updat= e
> (which would also carry the MAC/LID tuple) for providing metrics on a = single
> LID, and adding or deleting prefixes for said LID.
>
> And, at least in this case, a MAC is always a MAC... ;-)
>
> Just a thought.
>
> Regards,
> Stan


--001a1143e748ed60730558eaf65c-- From nobody Mon Sep 11 07:46:01 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DBC1323B4 for ; Mon, 11 Sep 2017 07:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Y5xZBOrYNl55 for ; Mon, 11 Sep 2017 07:45:59 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1A71321B6 for ; Mon, 11 Sep 2017 07:45:58 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id a128so18963925qkc.5 for ; Mon, 11 Sep 2017 07:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=gkPfAUZCfvCBy8j6kJwh79OpJKsniykqHNmWe8RhZjI=; b=JzkvUeDmt2p5d9kVGjgut/dooW2/l9tEVFC5+Sm+QF4wNlt8gqzTTcU0+eR010WmzH wG5dDjsSCX4425lufzd+ZEcV36c7sNQ3zRqJfJ6WFkA8y670/5vtrr0em7bmHX3aG/rc /J1IFKV4pA7fEqe5qHZ8p4rbwsFDKOMafOH4eQbUHSrysflbSFpl5nuMhJK81rUIL419 uiqkA8Ur6KMFT9+b9xd+VuCjF3k7dnzwYnA3IWpcLObG2O4RrVHkfkgiux48YJiZc+3A BNELGRIOCSNfqmd4njTbsYMH65sI+qDf67KetWt2xc9toOIEq9Hjs4JJETmiOvMQWM7+ QUzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=gkPfAUZCfvCBy8j6kJwh79OpJKsniykqHNmWe8RhZjI=; b=IxYWvVZxg7bMHbkyYHqhNhWQZfNQe+OTS1b/G4/WWSLyW4WazUnGbn2ANZzwqC585P zXEP/deRdbeMo1HC6ISNVQcO9PFok4Wym4FUaudMfyUZzhEDWFbcSODVvkZ6jFHb1g/w 4C1TvKWNsLlKGt5cnjztYkvo4RUqFbsqxoJ2icgA/w74+E+UipDzgFvC6z+hlJ28klIq 7d8+W8hQqH+/E3Vgrge/BEyexCk6EXvs7NfOC6QhItqQquE1z9auExb8X6duczmCFjWG p7TsHjLVz2XXyoZnTZ1QwqD3DmUmtHnhz4f3iOjMq8/QeTTYAlwP020Nzl0J9qgfwk7H PJAQ== X-Gm-Message-State: AHPjjUiW8NvgHVGJrwrzXGSkvVJ+Tiw4Tt3UHeBnJId0tE3/+bBXDHze YpqdkTjSDLdhV1qMFq+8nfz0bVctdOJlf2gs0Pk= X-Google-Smtp-Source: AOwi7QDCc+7UpPCvjZdJUt8qIYMOJ990FLPL9CHkjfmG9OtcGstc8OvXGTCVzXQ6bwgY8foXom19qkev7hR562k3O5A= X-Received: by 10.55.27.66 with SMTP id b63mr14618581qkb.338.1505141157894; Mon, 11 Sep 2017 07:45:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.50.229 with HTTP; Mon, 11 Sep 2017 07:45:27 -0700 (PDT) In-Reply-To: References: <1504863243.15735.13.camel@tropicalstormsoftware.com> <1504864640.15735.14.camel@tropicalstormsoftware.com> From: Henning Rogge Date: Mon, 11 Sep 2017 16:45:27 +0200 Message-ID: To: Stan Ratliff , MANET IETF , Rick Taylor Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 14:46:00 -0000 On Mon, Sep 11, 2017 at 4:42 PM, Stan Ratliff wrote: > Again, IIRC, some of the initial discussions on-list talked about a LID > length that was variable. That is something I'm opposed to, as it makes > searching them less efficient. The main thing I like about the notion that > sizeof(LID) == sizeof(MAC) is that I can put them in the same searchable > data structure (in my case, an AVL tree), Yes, I thought so too, but you can easily have a single AVL tree with different key lengths in it... just have the length field as the first part of your "comparator" function. > as long as they don't clash. I can > live with sizeof(LID) != sizeof(MAC), but I think that's sub-optimal. What I > see as really bad is the notion of a variable length LID. I would suggest setting a fixed length for the LID too... Henning From nobody Mon Sep 11 07:52:24 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0861321B6 for ; Mon, 11 Sep 2017 07:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pmb-rQ7kUGDS for ; Mon, 11 Sep 2017 07:52:22 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E291321C9 for ; Mon, 11 Sep 2017 07:52:21 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id v19so15403232ite.0 for ; Mon, 11 Sep 2017 07:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fuTx1Vh0Li8NOUjdRkZciTTGCiDjl1XVO9AjUxmfFYE=; b=MZMIIa7JEs16DV7TXYrJqxXynkUQKCEjimA8TTo4e3JmQSO7Fhw2B5UolJSiCnP0kK aQYGKWTx7omU9fQ158+fDxn95do6Db2FP2O5kABdpaXZNiAKNWASknb+vlNWPQdLpejY ITHyCSU2V2AXL0dtJBdWx9LtgmJ+b07RWIUqo8b1DLwXSdOGSgrMK00jy8SA8EyxYReU ZNFSUDhhYLnk+zlJLKFWZUN09v1MBsegDG6p3uyiBmmuL2u9zVu5HA23Tc2xnMRInRfV RyqdKCdijXUA18/v3OkdsrVG5LLLVuLvlkhaN40ffzIUd8yYZkPfEQrmR30JBIEnw+f0 lzdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fuTx1Vh0Li8NOUjdRkZciTTGCiDjl1XVO9AjUxmfFYE=; b=SGaD/d/DRFWuv4tBoeIEkRqDnT2Rv8G1W2iICH35IvPsStLxccNzGjYFWt6bW4nt94 mWsu8fTbQMzSfvnvN1H7rK/Z24ZrzCwWzGfkyWuV9lk06gIK5x6LtRk82SuRgE3XoH9G kEpcAFmWeUObtyArZCwT/UWGzUknNzzu3anJhDwyEBnih/hKelW4sq3d7Hsx18oHNcVq N2u4xV+lyiLOGg7/ZrKU6Kck60Xc3GCtCYVO6TGtA5mn3Tf5kqxtkFGXb/FEkJ2I1YAp wE6rIlW0FYZ7LzCtJOIuYUhLNp+yxsqpBHYJmBfFkPCDkqD7wloEjMr3pGlJ536/lyHw DGfQ== X-Gm-Message-State: AHPjjUjljf9jTWjh2wr+6zOhKY3UE3WNB3gjL09YY8PS4Q6qeUZZ9C7C 4hiIoaTwONLzcyoMDwnC2bhQ1X3N8w== X-Google-Smtp-Source: AOwi7QAafpNu2CS1VcWYpLc8//VGDcrQDydJ+QdVCVqb2hnuvRdqScsPD8BfeUi85rpo8/sZMHt9pVRgGSrK4Qwb4sk= X-Received: by 10.36.101.12 with SMTP id u12mr12294150itb.135.1505141541140; Mon, 11 Sep 2017 07:52:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.124.138 with HTTP; Mon, 11 Sep 2017 07:52:20 -0700 (PDT) In-Reply-To: References: <1504863243.15735.13.camel@tropicalstormsoftware.com> <1504864640.15735.14.camel@tropicalstormsoftware.com> From: Stan Ratliff Date: Mon, 11 Sep 2017 10:52:20 -0400 Message-ID: To: Henning Rogge Cc: MANET IETF , Rick Taylor Content-Type: multipart/alternative; boundary="001a113f8700e581e00558eb12fa" Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 14:52:23 -0000 --001a113f8700e581e00558eb12fa Content-Type: text/plain; charset="UTF-8" On Mon, Sep 11, 2017 at 10:45 AM, Henning Rogge wrote: > On Mon, Sep 11, 2017 at 4:42 PM, Stan Ratliff > wrote: > > Again, IIRC, some of the initial discussions on-list talked about a LID > > length that was variable. That is something I'm opposed to, as it makes > > searching them less efficient. The main thing I like about the notion > that > > sizeof(LID) == sizeof(MAC) is that I can put them in the same searchable > > data structure (in my case, an AVL tree), > > Yes, I thought so too, but you can easily have a single AVL tree with > different key lengths in it... just have the length field as the first > part of your "comparator" function. > I'm most likely being dense here, but... I don't know of any way an AVL tree can be simultaneously balanced against two different keys. Especially keys of different lengths. Regards, Stan > > > as long as they don't clash. I can > > live with sizeof(LID) != sizeof(MAC), but I think that's sub-optimal. > What I > > see as really bad is the notion of a variable length LID. > > I would suggest setting a fixed length for the LID too... > > Henning > --001a113f8700e581e00558eb12fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Sep 11, 2017 at 10:45 AM, Henning Rogge <<= a href=3D"mailto:hrogge@gmail.com" target=3D"_blank">hrogge@gmail.com&g= t; wrote:
On Mon, Sep 11, 2017 at = 4:42 PM, Stan Ratliff <ratliffs= tan@gmail.com> wrote:
> Again, IIRC, some of the initial discussions on-list talked about a LI= D
> length that was variable. That is something I'm opposed to, as it = makes
> searching them less efficient. The main thing I like about the notion = that
> sizeof(LID) =3D=3D sizeof(MAC) is that I can put them in the same sear= chable
> data structure (in my case, an AVL tree),

Yes, I thought so too, but you can easily have a single AVL tree with
different key lengths in it... just have the length field as the first
part of your "comparator" function.

I'm most likely being dense here, but... I don't know of any= way an AVL tree can be simultaneously balanced against two different keys.= Especially keys of different lengths.=C2=A0

Regar= ds,
Stan
=C2=A0

> as long as they don't clash. I can
> live with sizeof(LID) !=3D sizeof(MAC), but I think that's sub-opt= imal. What I
> see as really bad is the notion of a variable length LID.

I would suggest setting a fixed length for the LID too...

Henning

--001a113f8700e581e00558eb12fa-- From nobody Mon Sep 11 07:58:08 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C571330A6 for ; Mon, 11 Sep 2017 07:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LKd1pVuRgjws for ; Mon, 11 Sep 2017 07:58:05 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87460132D89 for ; Mon, 11 Sep 2017 07:58:05 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id i50so19613165qtf.0 for ; Mon, 11 Sep 2017 07:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WoKjdjTMWn7LUbv43CY8zl88eiE/HpszOjHZLLiM6i0=; b=mXvG7tGS70Z5y5EMoma+0D02iiKOKOk69J6qvJj1zyGaFjiZHUvBc8JNel7SAlFCwE MhWNYzvRdAEb+Meks5dy+bKvZVwCWgb6StoMLoYwTRMiUeZW+1RKuwJxjcwlITr/6ZBP xWiKgzSbOpS8QK7VbFzDyiWlfWE2m4LsOOBYjbg2BEUhZeF4VBVtmue1s6DAyvAmBbOQ ZRe5/WNYcEdQg+XmU1nggYs865yYGDK+XJqOSqXs/BbYqJ1xTuzZ+mTXNdUPRN6VQyou 3rRphjP9BY6UkmV0fFBYOCFWCwD+A6Dy8TmGQ7cxfhnhx2sP8avLrkcNv2lp6waBb54P 0hqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WoKjdjTMWn7LUbv43CY8zl88eiE/HpszOjHZLLiM6i0=; b=ohxUGtKEb9eoaPjJVJLdQZE1qz3w/BirvNBlntCyGq1lVSS22fgQKp+1vMO3CWimCQ nc9fufW9zc12MNI2+GPTo8ba49PwTSNRjin+W75WYNqeDNa4cHC1NsWmcuGJ1NXisU0U bmOldtuQUdJqOhAP98IvkFcWBE3HislWcIgP/j7xjUJpu6mEuh6WR0sMgzllWZa3QN28 fsPlcqGJGCbkH1GD7Zqp28W6TPF8RH/S5ggyFfIcDio1o9gJEYEV0gvDHRQGqnGXn2o0 NdywIfN2aHexk0CbNuzrYxu/LlOc+nZ742es/fg/Uy+E8Cb7hRmjffEb7yPG7a/V59R+ JYBg== X-Gm-Message-State: AHPjjUggsxqdQjwxz+NvQU+ei0it0J8qtqH3SL5b+ZJwYJBOtWsjQx0L bk6kDlh5xTsQ7nO5j3oWjno8whej0T85yUbgOWxjVS36 X-Google-Smtp-Source: AOwi7QCOF+tS59ZZBlWhdUQjnkBCNWc2McaWUt0TfvRBGA0IFFnAiHRYykzt5HYWXx4joPOurzCLbPmVKBfE2YNuRNk= X-Received: by 10.200.15.74 with SMTP id l10mr17392441qtk.159.1505141884607; Mon, 11 Sep 2017 07:58:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.50.229 with HTTP; Mon, 11 Sep 2017 07:57:34 -0700 (PDT) In-Reply-To: References: <1504863243.15735.13.camel@tropicalstormsoftware.com> <1504864640.15735.14.camel@tropicalstormsoftware.com> From: Henning Rogge Date: Mon, 11 Sep 2017 16:57:34 +0200 Message-ID: To: Stan Ratliff Cc: MANET IETF , Rick Taylor Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 14:58:07 -0000 On Mon, Sep 11, 2017 at 4:52 PM, Stan Ratliff wrote: >> Yes, I thought so too, but you can easily have a single AVL tree with >> different key lengths in it... just have the length field as the first >> part of your "comparator" function. > > I'm most likely being dense here, but... I don't know of any way an AVL tree > can be simultaneously balanced against two different keys. Especially keys > of different lengths. Each AVL tree needs ONE function that compares key A to key B and tells you "smaller, equal, larger". int comp_keys(key1, key2) { if len(key1) > len(key) { return larger; if len(key1) < len(key) { return smaller; /* these keys will have the same length */ return cmp(key1, key2, len(key1)); } The trick is to combine both factors into a single key to compare. Henning From nobody Tue Sep 12 02:36:59 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7AB13331E for ; Tue, 12 Sep 2017 02:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 JDoP_1Yqs7p0 for ; Tue, 12 Sep 2017 02:36:56 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7AE2133011 for ; Tue, 12 Sep 2017 02:36:55 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 12 Sep 2017 10:36:31 +0100 From: Rick Taylor To: "hrogge@gmail.com" , "ratliffstan@gmail.com" , "manet@ietf.org" Thread-Topic: [manet] Thoughts on draft-dlep-lid Thread-Index: AQHTKIZj53J9/AH/OUGjxC7M5WHHyKKqr+gAgABVuYCABD6cgIAAhBPWgAEqtQA= Date: Tue, 12 Sep 2017 09:35:06 +0000 Message-ID: <1505208906.15735.24.camel@tropicalstormsoftware.com> References: <1504863243.15735.13.camel@tropicalstormsoftware.com> <1504864640.15735.14.camel@tropicalstormsoftware.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <4333fd0e-0c42-4944-b3d4-7f51f50601f6> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 09:36:57 -0000 U29ycnksIEkgd2FzIGF3YXkgZnJvbSBteSBtYWNoaW5lIHllc3RlcmRheSwgIGNvbW1lbnRzIGlu bGluZS4uLg0KDQpPbiBNb24sIDIwMTctMDktMTEgYXQgMTY6NDUgKzAyMDAsIEhlbm5pbmcgUm9n Z2Ugd3JvdGU6DQo+IE9uIE1vbiwgU2VwIDExLCAyMDE3IGF0IDQ6NDIgUE0sIFN0YW4gUmF0bGlm ZiA8cmF0bGlmZnN0YW5AZ21haWwuY29tPg0KPiB3cm90ZToNCj4gPiBBZ2FpbiwgSUlSQywgc29t ZSBvZiB0aGUgaW5pdGlhbCBkaXNjdXNzaW9ucyBvbi1saXN0IHRhbGtlZCBhYm91dCBhDQo+ID4g TElEDQo+ID4gbGVuZ3RoIHRoYXQgd2FzIHZhcmlhYmxlLiBUaGF0IGlzIHNvbWV0aGluZyBJJ20g b3Bwb3NlZCB0bywgYXMgaXQNCj4gPiBtYWtlcw0KPiA+IHNlYXJjaGluZyB0aGVtIGxlc3MgZWZm aWNpZW50LiBUaGUgbWFpbiB0aGluZyBJIGxpa2UgYWJvdXQgdGhlDQo+ID4gbm90aW9uIHRoYXQN Cj4gPiBzaXplb2YoTElEKSA9PSBzaXplb2YoTUFDKSBpcyB0aGF0IEkgY2FuIHB1dCB0aGVtIGlu IHRoZSBzYW1lDQo+ID4gc2VhcmNoYWJsZQ0KPiA+IGRhdGEgc3RydWN0dXJlIChpbiBteSBjYXNl LCBhbiBBVkwgdHJlZSksDQo+IA0KPiBZZXMsIEkgdGhvdWdodCBzbyB0b28sIGJ1dCB5b3UgY2Fu IGVhc2lseSBoYXZlIGEgc2luZ2xlIEFWTCB0cmVlIHdpdGgNCj4gZGlmZmVyZW50IGtleSBsZW5n dGhzIGluIGl0Li4uIGp1c3QgaGF2ZSB0aGUgbGVuZ3RoIGZpZWxkIGFzIHRoZQ0KPiBmaXJzdA0K PiBwYXJ0IG9mIHlvdXIgImNvbXBhcmF0b3IiIGZ1bmN0aW9uLg0KPiANCj4gPiBhcyBsb25nIGFz IHRoZXkgZG9uJ3QgY2xhc2guIEkgY2FuDQo+ID4gbGl2ZSB3aXRoIHNpemVvZihMSUQpICE9IHNp emVvZihNQUMpLCBidXQgSSB0aGluayB0aGF0J3Mgc3ViLQ0KPiA+IG9wdGltYWwuIFdoYXQgSQ0K PiA+IHNlZSBhcyByZWFsbHkgYmFkIGlzIHRoZSBub3Rpb24gb2YgYSB2YXJpYWJsZSBsZW5ndGgg TElELg0KPiANCj4gSSB3b3VsZCBzdWdnZXN0IHNldHRpbmcgYSBmaXhlZCBsZW5ndGggZm9yIHRo ZSBMSUQgdG9vLi4uDQoNCkV4Y2VsbGVudCwgdGhpcyBtaXJyb3JzIHRoZSBlYXJsaWVyIGRpc2N1 c3Npb24sIHdoZXJlIHdlIGNvbmNsdWRlZCB0aGF0DQphIGZpeGVkIGxlbmd0aCBMSUQgaXMgdGhl IGJlc3QgY29tcHJvbWlzZS4NCg0KV2hhdCB3ZSBhbHNvIHByZXZpb3VzbHkgZGlzY3Vzc2VkIHdh cyBob3cgZG9lcyBvbmUgbmVnb3RpYXRlIHRoZSBsZW5ndGgNCm9mIGEgTElELiAgVGhlIG9wdGlv bnMgcHV0IGZvcndhcmQgd2VyZToNCg0KYSkgWW91IGRvbid0OiBUTFZzIGhhdmUgYSBsZW5ndGgg ZmllbGQsIHNvIGxvb2sgYXQgdGhhdC4NCg0KYikgTElEcyBNVVNUIGJlIGFuIGFyYml0cmFyeSAz MmJpdCB1bnNpZ25lZCBpbnQuDQoNCmMpIEEgJ0xJRCBMZW5ndGggQW5ub3VuY2UnIERhdGEgSXRl bSB1c2VkIGF0IFNlc3Npb24gSW5pdC4NCg0KZCkgTElEcyBNVVNUIGJlIHRoZSBzYW1lIGxlbmd0 aCBhcyB0aGUgTUFDcyB1c2VkIG9uIHRoZSBsaW5rIGNhcnJ5aW5nDQp0aGUgRExFUCBzZXNzaW9u Lg0KDQpBZnRlciBkaXNjdXNzaW9uLCB0aGUgY29uY2x1c2lvbiB3YXMgb3B0aW9uIGQgd2FzIHRo ZSBiZXN0IGNvbXByb21pc2UsDQphbmQgaXMgd2hhdCBpcyBkZXNjcmliZWQgaW7CoGRyYWZ0LWRs ZXAtbGlkLTAxICh3aGljaCBpcyBhbiBpbmNvcnJlY3QNCm5hbWUgSSBjb3VsZCBmaXgsIGJ1dCBJ J20gaG9waW5nIHRvIHJlbmFtZSBhc8KgZHJhZnQtbWFuZXQtZGxlcC1saWQtMDApDQoNCkNoZWVy cywNCg0KUmljaw0K From nobody Tue Sep 12 04:36:25 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC765133460 for ; Tue, 12 Sep 2017 04:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 orV1_RT7z97c for ; Tue, 12 Sep 2017 04:36:22 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341A91333E0 for ; Tue, 12 Sep 2017 04:36:22 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id b23so24324474qkg.1 for ; Tue, 12 Sep 2017 04:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wiy77L4cnTM9m7/fC2qJXp+XsRGXWa42RF7RehLJQzA=; b=OUSCO5X6j+vNRiet7ihQuEtKc1aAFAACwq4pv5DtOLzkCZWn1iHDgMhhw7Xbu9iNeE oQzfz3csL8nacOnbdk2hGKff3lb2HBk1oP1zvsMtFwvJoDxG8RB8WdMhXumRT8cclYv7 VzDai0QwBVOmowWXrv4WIYzbJ97moouhU2S7au4FoyNhwPpEkgEHObrCbcYEEMjw4B3Z n/CIl8Y/EN7sM+tKf3KMn36V9ohX5qS7Kh+BfYLwFKJjYg5YhTMrmx2/nEiLUaqalfwi Mj5GNuKWfeDrz9QteQGXh2nXd0aTHGhtvHnVPXpVhqKIkedDc2G88HSCEXWjNBN76mf7 ZMUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wiy77L4cnTM9m7/fC2qJXp+XsRGXWa42RF7RehLJQzA=; b=LhGxnQG4+uYTq3dUp7OwxXWXFwu0OrVqY0YAl/vXvArjp5BHRFvtYv0ba2t3oIshWC r7xaQszt0mEaU1/b8wRCver9Khw9lcgsF/t6mQpUj4X52WYbUYAHSTiRb3n5fAI0XENA Cl7bDYJ+05pzqo//YN4FsI7IVtQCcVmnAh9oWiwG5NpttiKjJy2u1DyQn+IN4m+n18kX TMWEw3cfBbMPrvEXduABm/QrwqMIpssku4pzJKbl3xa++E3YwuWDhJGI047DBmvsfrJw O5vPd/WJcQArSU42KBfH77eH4LWe2As2IQ1HZhibAmtyM+QNjB8WI3pGE47buhqQSCLv G2Fg== X-Gm-Message-State: AHPjjUgAmgUMoYIRGd+DF545OHnc1dghKcYoOWwn5zhrevv64OeaBNm4 Jcb/O+pCyGqidA8nGc82bemAcs5HvC4A6ykolskyLg== X-Google-Smtp-Source: AOwi7QC3Xs6vKB2YbvrDn7Cnil0KREC62XXVI3DMPai+ofJDLJzKmTOeCzRMEfbGxdjtURkg/0hHfM6KHYjF6hAwRBY= X-Received: by 10.55.122.130 with SMTP id v124mr707879qkc.209.1505216181085; Tue, 12 Sep 2017 04:36:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.50.229 with HTTP; Tue, 12 Sep 2017 04:35:50 -0700 (PDT) In-Reply-To: <1505208906.15735.24.camel@tropicalstormsoftware.com> References: <1504863243.15735.13.camel@tropicalstormsoftware.com> <1504864640.15735.14.camel@tropicalstormsoftware.com> <1505208906.15735.24.camel@tropicalstormsoftware.com> From: Henning Rogge Date: Tue, 12 Sep 2017 13:35:50 +0200 Message-ID: To: Rick Taylor Cc: "ratliffstan@gmail.com" , "manet@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 11:36:24 -0000 On Tue, Sep 12, 2017 at 11:35 AM, Rick Taylor wrote: > Sorry, I was away from my machine yesterday, comments inline... > > On Mon, 2017-09-11 at 16:45 +0200, Henning Rogge wrote: >> I would suggest setting a fixed length for the LID too... > > Excellent, this mirrors the earlier discussion, where we concluded that > a fixed length LID is the best compromise. Yes. > After discussion, the conclusion was option d was the best compromise, > and is what is described in draft-dlep-lid-01 (which is an incorrect > name I could fix, but I'm hoping to rename as draft-manet-dlep-lid-00) I was this opinion too, but I think there are disadvantages in choosing the same length... including the problem of mixing them up with MAC addresses (and the question if you are allowed to choose a LID that is also be used as a MAC address). Henning From nobody Tue Sep 12 06:59:58 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49AB1132716 for ; Tue, 12 Sep 2017 06:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 qiF4RHnDpUP7 for ; Tue, 12 Sep 2017 06:59:55 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA061326DF for ; Tue, 12 Sep 2017 06:59:55 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 12 Sep 2017 14:59:31 +0100 From: Rick Taylor To: "hrogge@gmail.com" CC: "ratliffstan@gmail.com" , "manet@ietf.org" Thread-Topic: [manet] Thoughts on draft-dlep-lid Thread-Index: AQHTKIZj53J9/AH/OUGjxC7M5WHHyKKqr+gAgABVuYCABD6cgIAAhBPWgAEqtQCAACG7AIAAJ8IA Date: Tue, 12 Sep 2017 13:58:08 +0000 Message-ID: <1505224688.15735.32.camel@tropicalstormsoftware.com> References: <1504863243.15735.13.camel@tropicalstormsoftware.com> <1504864640.15735.14.camel@tropicalstormsoftware.com> <1505208906.15735.24.camel@tropicalstormsoftware.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <1ba4a18b-9fec-43b4-bb99-0227aff82069> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 13:59:57 -0000 T24gVHVlLCAyMDE3LTA5LTEyIGF0IDEzOjM1ICswMjAwLCBIZW5uaW5nIFJvZ2dlIHdyb3RlOg0K PiBPbiBUdWUsIFNlcCAxMiwgMjAxNyBhdCAxMTozNSBBTSwgUmljayBUYXlsb3INCj4gPHJpY2tA dHJvcGljYWxzdG9ybXNvZnR3YXJlLmNvbT4gd3JvdGU6DQo+ID4gU29ycnksIEkgd2FzIGF3YXkg ZnJvbSBteSBtYWNoaW5lIHllc3RlcmRheSzCoMKgY29tbWVudHMgaW5saW5lLi4uDQo+ID4gDQo+ ID4gT24gTW9uLCAyMDE3LTA5LTExIGF0IDE2OjQ1ICswMjAwLCBIZW5uaW5nIFJvZ2dlIHdyb3Rl Og0KPiA+ID4gSSB3b3VsZCBzdWdnZXN0IHNldHRpbmcgYSBmaXhlZCBsZW5ndGggZm9yIHRoZSBM SUQgdG9vLi4uDQo+ID4gDQo+ID4gRXhjZWxsZW50LCB0aGlzIG1pcnJvcnMgdGhlIGVhcmxpZXIg ZGlzY3Vzc2lvbiwgd2hlcmUgd2UgY29uY2x1ZGVkDQo+ID4gdGhhdA0KPiA+IGEgZml4ZWQgbGVu Z3RoIExJRCBpcyB0aGUgYmVzdCBjb21wcm9taXNlLg0KPiANCj4gWWVzLg0KPiANCj4gPiBBZnRl ciBkaXNjdXNzaW9uLCB0aGUgY29uY2x1c2lvbiB3YXMgb3B0aW9uIGQgd2FzIHRoZSBiZXN0DQo+ ID4gY29tcHJvbWlzZSwNCj4gPiBhbmQgaXMgd2hhdCBpcyBkZXNjcmliZWQgaW4gZHJhZnQtZGxl cC1saWQtMDEgKHdoaWNoIGlzIGFuDQo+ID4gaW5jb3JyZWN0DQo+ID4gbmFtZSBJIGNvdWxkIGZp eCwgYnV0IEknbSBob3BpbmcgdG8gcmVuYW1lIGFzIGRyYWZ0LW1hbmV0LWRsZXAtbGlkLQ0KPiA+ IDAwKQ0KPiANCj4gSSB3YXMgdGhpcyBvcGluaW9uIHRvbywgYnV0IEkgdGhpbmsgdGhlcmUgYXJl IGRpc2FkdmFudGFnZXMgaW4NCj4gY2hvb3NpbmcgdGhlIHNhbWUgbGVuZ3RoLi4uIGluY2x1ZGlu ZyB0aGUgcHJvYmxlbSBvZiBtaXhpbmcgdGhlbSB1cA0KPiB3aXRoIE1BQyBhZGRyZXNzZXMgKGFu ZCB0aGUgcXVlc3Rpb24gaWYgeW91IGFyZSBhbGxvd2VkIHRvIGNob29zZSBhDQo+IExJRCB0aGF0 IGlzIGFsc28gYmUgdXNlZCBhcyBhIE1BQyBhZGRyZXNzKS4NCg0KVGhlIGRyYWZ0IHNheXM6DQoN CiIuLi5Sb3V0ZXIgaW1wbGVtZW50YXRpb25zIE1VU1QgTk9UIGFzc3VtZSB0aGF0IExJRHMgd2ls bCBub3QgY2xhc2gNCndpdGggYW55IE1BQyBBZGRyZXNzIERhdGEgSXRlbXMgYWxzbyBpbiB1c2Ug ZHVyaW5nIHRoZSBETEVQIHNlc3Npb24sDQpMSURzIGV4aXN0IGluIGEgc2VwYXJhdGUgbnVtYmVy aW5nIHNwYWNlLiINCg0KVG8gYXZvaWQgdGhhdCBoYXphcmQuICBJIGNvdWxkbid0IHRoaW5rIG9m IGFueSBvdGhlciB3YXkgb2YgcG9pbnRpbmcNCm91dCB0aGUgZGlmZmVyZW5jZS4gIFJlYWxseSwg aWYgeW91IG1peCB0aGVtIHVwIHRoZW4geW91J3JlIG5vdCByZWFkaW5nDQp0aGUgc3BlYyBjbGVh cmx5LCBvciBpdCdzIGEgYnVnLg0KDQpSaWNr From nobody Tue Sep 12 07:03:59 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B568E1326DF for ; Tue, 12 Sep 2017 07:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 g9mvD93CmGWM for ; Tue, 12 Sep 2017 07:03:51 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410EB133063 for ; Tue, 12 Sep 2017 07:03:51 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id v36so34681126ioi.1 for ; Tue, 12 Sep 2017 07:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fV1JoRSEfUe1E0ukdnuU6cFX0bFvHL3hClV1O5Xqpec=; b=KtvAeWOCpHbRXvh7Y8ujw4vKBEh43Xfx7lBfns0SNirlz0PUW+N6SPpMpm37Rr8YDT s28TQKhvzLUKdOPkqddE2RFEJHgi8OmaLUjRVJPb1Ok0ZNAZGntknrx+T4QO+zjOLEy+ MQwF1ZlXE911Ktp8zOA28tNaN+Nikd+L2RJIOHjgrCz61FBAQTybXoJIXbpuVq60OTz1 gRzhcWvqkzC1L7UHnynApT8v35GemQYbOF35Opzi0F1qho9hw/9zAJWLVcGJHEp6XmEI znv/Y4zf+QXPkDu6m2lPaWwV8zXY8RkRxcb8D6jA2fc8WuhYbmxwfyowJ45EPr0Ol8X6 kzSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fV1JoRSEfUe1E0ukdnuU6cFX0bFvHL3hClV1O5Xqpec=; b=iqN5+veIUcDd3ZWlY5KF3SQ+m9VkwJY8g6mD13WJLgF0RUJBEUKINT1cLGzbuBrXLC lnzpDLJc76/HN7iPBWi2dojLdZyL17KLWyhI2/B+VwrXGiCD/vy6k18szCIIMZbm5pHi hbHBj5jRxUjMYB1B679EC7grGvl0ZjkY7rtre6Ad9dwcbCcJ8gfnZD5A24is80jYd4wm 7NECXtTCKqQZo9IMYdsYpGvtSpZQyM0+3iPQBfvNKduVWUtF4tQsx+5LpNKm0WXk3wGS d3ZX8yMh9IkQRT/HyTOAYfSh3ltTk/CG7F6EN1nwjjB6fSdl0wTtFbUFGwS9OdS4UhO/ anwQ== X-Gm-Message-State: AHPjjUhxEHHfmIzHzOD+1ir/av5hipiV2GkmKa2KnODqQ5cOXowrZFv9 J6y2NcqZ2lKcejizY4t3v/55PV9W/w== X-Google-Smtp-Source: AOwi7QDMxHyEsE5COniixpmQcmrTPYyGxTkFfSsYy9HF7qwJ/HrzJ+MG83XXCBkk8R1oy7zhqdvyS1+zLCq7zEzjMFM= X-Received: by 10.107.155.65 with SMTP id d62mr19132622ioe.220.1505225030506; Tue, 12 Sep 2017 07:03:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.124.138 with HTTP; Tue, 12 Sep 2017 07:03:49 -0700 (PDT) In-Reply-To: References: <1504863243.15735.13.camel@tropicalstormsoftware.com> <1504864640.15735.14.camel@tropicalstormsoftware.com> <1505208906.15735.24.camel@tropicalstormsoftware.com> From: Stan Ratliff Date: Tue, 12 Sep 2017 10:03:49 -0400 Message-ID: To: Henning Rogge Cc: Rick Taylor , "manet@ietf.org" Content-Type: multipart/alternative; boundary="001a114079d4401ba50558fe8386" Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 14:03:58 -0000 --001a114079d4401ba50558fe8386 Content-Type: text/plain; charset="UTF-8" On Tue, Sep 12, 2017 at 7:35 AM, Henning Rogge wrote: > On Tue, Sep 12, 2017 at 11:35 AM, Rick Taylor > wrote: > > Sorry, I was away from my machine yesterday, comments inline... > > > > On Mon, 2017-09-11 at 16:45 +0200, Henning Rogge wrote: > >> I would suggest setting a fixed length for the LID too... > > > > Excellent, this mirrors the earlier discussion, where we concluded that > > a fixed length LID is the best compromise. > > Yes. > > > After discussion, the conclusion was option d was the best compromise, > > and is what is described in draft-dlep-lid-01 (which is an incorrect > > name I could fix, but I'm hoping to rename as draft-manet-dlep-lid-00) > > I was this opinion too, but I think there are disadvantages in > choosing the same length... including the problem of mixing them up > with MAC addresses (and the question if you are allowed to choose a > LID that is also be used as a MAC address). > As for choosing a LID that is also a MAC - I'd say an emphatic no. One scheme is to mark the LIDs as Locally Administered Addresses. They're guaranteed not to clash with real MAC addresses. Regards, Stan --001a114079d4401ba50558fe8386 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 12, 2017 at 7:35 AM, Henning Rogge <hrogge@gmail.com>= ; wrote:
On Tue, Sep 12, 2017 at 1= 1:35 AM, Rick Taylor
<rick@tropicalstormsof= tware.com> wrote:
> Sorry, I was away from my machine yesterday,=C2=A0 comments inline...<= br> >
> On Mon, 2017-09-11 at 16:45 +0200, Henning Rogge wrote:
>> I would suggest setting a fixed length for the LID too...
>
> Excellent, this mirrors the earlier discussion, where we concluded tha= t
> a fixed length LID is the best compromise.

Yes.

> After discussion, the conclusion was option d was the best compromise,=
> and is what is described in draft-dlep-lid-01 (which is an incorrect > name I could fix, but I'm hoping to rename as draft-manet-dlep-lid= -00)

I was this opinion too, but I think there are disadvantages in
choosing the same length... including the problem of mixing them up
with MAC addresses (and the question if you are allowed to choose a
LID that is also be used as a MAC address).

=
As for choosing a LID that is also a MAC - I'd say an emphatic no.= One scheme is to mark the LIDs as Locally Administered Addresses. They'= ;re guaranteed not to clash with real MAC addresses. =C2=A0=C2=A0

Regards,
Stan

--001a114079d4401ba50558fe8386-- From nobody Tue Sep 12 07:05:32 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA3D132716 for ; Tue, 12 Sep 2017 07:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 sMrXS039jNh9 for ; Tue, 12 Sep 2017 07:05:29 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A731326DF for ; Tue, 12 Sep 2017 07:05:29 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id a128so25213160qkc.5 for ; Tue, 12 Sep 2017 07:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NVTXggIWhSRdhqp2/p7CBOQhtx1XwSjVVXC4SvBL6Dw=; b=Q7VzVVNMKjmOYkSWVw/pbJtTO+6CrEL4WRO3oINdrQxVZL3GALcWyM4FRF3Ff9DV6s bGIX44WrD7le/AXs/LEk2jBPJswthJTdX2j0h9ggRr/R/KjHGiUdqyw+0oxuWfMANm7E Rljp3Gp5kFcYLrjcVdCpMjSBqW+7+FGO10qhcJnk9D7yMMjjiVH00KpIdydYjC8XCM8n Ii+SP5r+CVhvzJ4LH6oDbQ+HVA4E6OSnBL7N1Rls55X5+HTJPAkT0G1Mj4oydRDINIDd aVgcYVWUhRmcVzKTgU2z1KpBJ3YSy+gWlO9B/GUgRJ1aiw2TfmaGRq3UXyxvw+++odkt R4KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NVTXggIWhSRdhqp2/p7CBOQhtx1XwSjVVXC4SvBL6Dw=; b=lZ6RBCv4zX4ltKtShSjpbLfL8nRPHVOptqpBbxYVi82ARhFbKPaH3d2cL3iG5BGqz3 AYUWGSFzxUIgxLWqSi0/4YXgHDwU5dbAmdzh40KUjkggrJ8ZYeTXYVFNAZ0Lq5m5hT6q Z7KNx6wBHq64yMKXUiRRS60HgzW3t5eckItUMr1NgZLlPEd4RKfvZaY3+HipB2Zir2da xhC8x6XDfaMne+RaSq7ui35DLS/8Hfvx7K+pDqWyotVi+ihYarYJeV33GdcLR8GqIvag GU0gvgsc/UyePiOFprPtHFOF2fFjIiLek+SN6h5Hc/k1yPerUhLDNgeRI/ZxJSLqrcWF 6h0w== X-Gm-Message-State: AHPjjUjCqa/WdoPdHQBoxcVgHyge6B2t/nx5Sr2f6Qjzea0ucm3gs1qd Ie3A73GvzeniY9eJuSon4pGkWnwrGdZWHc6SbzbgBA== X-Google-Smtp-Source: AOwi7QB1NXl2AFzf9r3QATwn+0R/09fpcOqUM2l7N5Amfcbn1WBGWh58yQRjHSW8sm+WQ1I8AkR6IoFgHcMY/PWrzCU= X-Received: by 10.55.27.66 with SMTP id b63mr18825694qkb.338.1505225127183; Tue, 12 Sep 2017 07:05:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.60.104 with HTTP; Tue, 12 Sep 2017 07:04:55 -0700 (PDT) In-Reply-To: References: <1504863243.15735.13.camel@tropicalstormsoftware.com> <1504864640.15735.14.camel@tropicalstormsoftware.com> <1505208906.15735.24.camel@tropicalstormsoftware.com> From: Henning Rogge Date: Tue, 12 Sep 2017 16:04:55 +0200 Message-ID: To: Stan Ratliff Cc: Rick Taylor , "manet@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 14:05:31 -0000 On Tue, Sep 12, 2017 at 4:03 PM, Stan Ratliff wrote: > As for choosing a LID that is also a MAC - I'd say an emphatic no. One > scheme is to mark the LIDs as Locally Administered Addresses. They're > guaranteed not to clash with real MAC addresses. What happens if one of my bridged routers uses a locally administrated address as a MAC too? Henning From nobody Tue Sep 12 07:08:44 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2F8132D43 for ; Tue, 12 Sep 2017 07:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 zWtVTSEbsvls for ; Tue, 12 Sep 2017 07:08:41 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B35132716 for ; Tue, 12 Sep 2017 07:08:41 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id c195so29357310itb.1 for ; Tue, 12 Sep 2017 07:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YzFhcpd22MD/ouWyUfbrflZvt7ftu1WJtkXit5Gp0tk=; b=Qqrp5soQ99FUi8K/XWr3NzVnRBIdv9PwhI01GQezroIJqTfzPLSOdwLba1bw7LzKLO bCzgp9luUZ7Dyc80eRvP1RQvMCkydCfClg4Sgh79j7WreS64PfKxljEPvJ3AD7RXuACT x6ufXS/MAJ7kVltfVlTjBqKQPNZKFrNALLcKxjbBMvn1B9f4GqfJ9hGxTXCaxRSIh271 mqmEXV/gdr7739UsHt43Lrz/G9xuZC2s/BjpN6RLppN0nbm49r23aif8rKaov/6KEMfY AvpTysa3e3mLf4klOA3ZCjIZqCHqJ8JsBfa0QNWgAJXzH8Adp+3w08n3j4A7CMPL6yr+ Qvwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YzFhcpd22MD/ouWyUfbrflZvt7ftu1WJtkXit5Gp0tk=; b=uDrcb3Iu4jLLyvr1ZLK4XebQ2SPtMpLU/28Yars92aZnZPMOk/uhsv4HNDaTkBWkY4 BehYWHWl3Xp0qI7wJ94dG/LOnD91YM8ZKifyj8d4H8EpefQxhFlmOEHOgczYSF4n0GJJ /IBxbiZB4a5XVBlV+NtWnucrsFkgGHbd5c+v9naMwHx4Dj/rYqibdtK3RT2dKOJp7G51 PyoeN+Vtk980yMkpy/OWbAk0D39JlkvbSFLGdS5XTmmFB4mbs7DB+j4mjnPbkuJr5CNm HabPTULM24g1Bx5nZCxy4qYu39/jvUoOwPtgh2e9N3T3+nnOab3mrFEdrsTqV+8Szz8q 2AbQ== X-Gm-Message-State: AHPjjUijylVf1kMMlahg8niEbWxAmB9hbcIPDOwPtToKqR+n8oU+C0yj ajpVDYhVzNbtu+2cC7wWSBjRAuCtGg== X-Google-Smtp-Source: AOwi7QB/Hm7IZkl9cJU2xoN3gJKO39FFXdr+aiiack882MzVJH4Tw7yHY4GIB4+Ws+EolKosltNx/ax0/4vejg7eq9o= X-Received: by 10.36.101.12 with SMTP id u12mr1137148itb.135.1505225320507; Tue, 12 Sep 2017 07:08:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.124.138 with HTTP; Tue, 12 Sep 2017 07:08:39 -0700 (PDT) In-Reply-To: References: <1504863243.15735.13.camel@tropicalstormsoftware.com> <1504864640.15735.14.camel@tropicalstormsoftware.com> <1505208906.15735.24.camel@tropicalstormsoftware.com> From: Stan Ratliff Date: Tue, 12 Sep 2017 10:08:39 -0400 Message-ID: To: Henning Rogge Cc: Rick Taylor , "manet@ietf.org" Content-Type: multipart/alternative; boundary="001a113f8700892ec70558fe94ea" Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 14:08:42 -0000 --001a113f8700892ec70558fe94ea Content-Type: text/plain; charset="UTF-8" On Tue, Sep 12, 2017 at 10:04 AM, Henning Rogge wrote: > On Tue, Sep 12, 2017 at 4:03 PM, Stan Ratliff > wrote: > > As for choosing a LID that is also a MAC - I'd say an emphatic no. One > > scheme is to mark the LIDs as Locally Administered Addresses. They're > > guaranteed not to clash with real MAC addresses. > > What happens if one of my bridged routers uses a locally administrated > address as a MAC too? > A couple of questions there - first, why would the bridged router not use the burned-in MAC? Secondly, if you're using randomly-generated suffixes for the LAAs, then your chance of collision is very small. Regards, Stan --001a113f8700892ec70558fe94ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 12, 2017 at 10:04 AM, Henning Rogge <<= a href=3D"mailto:hrogge@gmail.com" target=3D"_blank">hrogge@gmail.com&g= t; wrote:
On Tu= e, Sep 12, 2017 at 4:03 PM, Stan Ratliff <ratliffstan@gmail.com> wrote:
> As for choosing a LID that is also a MAC - I'd say an emphatic no.= One
> scheme is to mark the LIDs as Locally Administered Addresses. They'= ;re
> guaranteed not to clash with real MAC addresses.

What happens if one of my bridged routers uses a locally administrated
address as a MAC too?

A couple of quest= ions there - first, why would the bridged router not use the burned-in MAC?= Secondly, if you're using randomly-generated suffixes for the LAAs, th= en your chance of collision is very small.=C2=A0

R= egards,
Stan

--001a113f8700892ec70558fe94ea-- From nobody Tue Sep 12 07:13:00 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6638E132716 for ; Tue, 12 Sep 2017 07:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 gsQMnyFGWaNV for ; Tue, 12 Sep 2017 07:12:53 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 304AE1326DF for ; Tue, 12 Sep 2017 07:12:53 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id b82so25284480qkc.4 for ; Tue, 12 Sep 2017 07:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PrwhVZ0fP5fqQgoruRVv73afMSkfydRVlWulIldzGMk=; b=O9ymWyUgsc2vNBJYejsVvVPbTmR5XXKV6TGz4t9629iR4xzwexnzFZ+QzXCS428LGU 8igLbLy850BcIpkRSfwvQI8WadOzmU8a736xhtbDz2vQPYtfk9wu8mW9fnYl/OX3W6eO +ZF8gVITKiQw/B7UuxSww7zinhgX8pWX9k3kGRtPlOuoj/9g9fJCjCcjPoeLDDbuAvtM /FGSvjb6cwSTj/2Tr/TSCOa2JSGNDmHBpbl/hcaIgy2CF6gej4QEbLOzJhaVfpllVJdX jqBbvD/l5n60NNlQEXin7BJoMO6o7xMrcHg4kUaV0g8qYgOM5YZ+Bvpy6YAtScJy5yrb 0FbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PrwhVZ0fP5fqQgoruRVv73afMSkfydRVlWulIldzGMk=; b=toq6pJ1d0SqgmI6EL+QHxyaKZEkTmwL8QDCFQEX+hTGcndsug9y1LDg08ukKbAYxGx o/ApBmsM+AgX6KdCrgM3Geo8JHPf43ZODviv3/XMGRQpJMYF/nWxiaLSyAUP43mtZ7yv Js8DTHuz/+5bFnaqWzvLrcZvIhTkUywC/KzWIbCUgPCATAkqambJckcgfa1w33VJ6b1E B3FoIUVNsH9g9nzh9//g5itWDSLPNyVp/bGihbwordAyx4GA8BZfvI1+K2GRJM67rby9 lfW28ryGynA3LblPAjkjPSMZgqZIIyXVoYZx5UvY9jBmFD3XIZBHrRJ2tguaJKW/o5uM uM7w== X-Gm-Message-State: AHPjjUjYvQaV4OSNPkXnkH4aQ9JiGW3+HmqJp5yYeGtKhGAEY+gznccA nE0RUOiMhmDatp/+bMfy6/OhrGV77uQADrVbhTg= X-Google-Smtp-Source: AOwi7QDOnu31W9jMhetEsfHOxuQEhB7uKezFezOcqQ92hOHdnaEp+UbSmqnZaqR0p880hraRd3pCJatNgMjxlGJRWkc= X-Received: by 10.55.27.66 with SMTP id b63mr18865435qkb.338.1505225572180; Tue, 12 Sep 2017 07:12:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.60.104 with HTTP; Tue, 12 Sep 2017 07:12:21 -0700 (PDT) In-Reply-To: References: <1504863243.15735.13.camel@tropicalstormsoftware.com> <1504864640.15735.14.camel@tropicalstormsoftware.com> <1505208906.15735.24.camel@tropicalstormsoftware.com> From: Henning Rogge Date: Tue, 12 Sep 2017 16:12:21 +0200 Message-ID: To: Stan Ratliff Cc: Rick Taylor , "manet@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 14:12:59 -0000 On Tue, Sep 12, 2017 at 4:08 PM, Stan Ratliff wrote: > On Tue, Sep 12, 2017 at 10:04 AM, Henning Rogge wrote: >> What happens if one of my bridged routers uses a locally administrated >> address as a MAC too? > > A couple of questions there - first, why would the bridged router not use > the burned-in MAC? Secondly, if you're using randomly-generated suffixes for > the LAAs, then your chance of collision is very small. Either we should say "LID is a 'virtual MAC' and DLEP must make sure not to collide"... or it is not a MAC and from a different namespace and we should not care. The same train of thoughts made me think about extending the LID to 16 bytes to make it really different (and make it easy to use all kind of input including IPv6 addresses to generate them). Henning From nobody Tue Sep 12 07:19:07 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEEFA133052 for ; Tue, 12 Sep 2017 07:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 iyuxny8Entyl for ; Tue, 12 Sep 2017 07:19:03 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E6951326DF for ; Tue, 12 Sep 2017 07:19:03 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id 6so23840506itl.1 for ; Tue, 12 Sep 2017 07:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w1pNE27fjRPKOfEY8z+hgrQIp8ron4FTF/n9Y/PgDS8=; b=d4YST2FxbqeYN0oJiJizlfOaR7RBCUFXlH2KglGrkpKMneeqe7neSxRC8Ze6QCmbEH k0wGNwY+0eSQcub9bZmmGrR544NtO2OsVFUyR7qUlloLUld/zaQVZSrTNkfVZ29r0W98 9cgnJ1GU+85bQ8tiUIKBkhlCprqITTsbt0eP3bn7eQ4elUQaYQf2f0Ns4qEcoMtCkPrW 6uN4Ra/uqqZEPSbGNHuCkMzZJAyXmbO+ZxykTGtS4t2MWCZJwxQdD/gIhYXURF2aCTuv jt22TKQGBDivB3/4krKBUdrcgMDL3Lhn9dPkRWREllEeTng44dN/fsUzqHZMvccJRoZu 5amg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w1pNE27fjRPKOfEY8z+hgrQIp8ron4FTF/n9Y/PgDS8=; b=jvGGxGi+lSNmw6Z7YNC6sVZs7ABpM92QdFmajK6o88NFqBl+YhrKR9LrZXxutrdvAw KAKQ70Hb3GMfsFwhTGC/iUAfv7NrJAp2BNlVIDk8eenh/oZFtC2kJ2fCK2Yg+JoebtOf qFXmrHL5p+FW5i/GDtVdWSqrJdH62ZyCjFvvVuqt5KA5ltp/8rw7YeCnYL2nMNdow7hV JN4ZQ+Kvd5zcrU6Il5DbT6lskzX0wg8nTnCwtbUaIehSjDtErwnGE4SzoYtdSEjs3jVQ VKsKnN6rIdbbWeClN4tLKNYvfmsFk4WLW40bkInDvauzuXu0ZnbI9aQkezAxhjBcIU33 ezcQ== X-Gm-Message-State: AHPjjUjdM0AEzCjc6MoXKlN/RoEWytNyAxjMr5tsAJtiNlvs1xwkkXTO LqaW35pQ+FPgMZVd+EKumimTx96Avw== X-Google-Smtp-Source: AOwi7QDzpVwfzuqMC5IAt7FbSxn7EnIsCwV+KnVoA39w58rygA78yxNWq+XuVsg8qITeoKftxt40DiPmeTGf9HFH+1Y= X-Received: by 10.36.177.9 with SMTP id o9mr1109343itf.44.1505225942524; Tue, 12 Sep 2017 07:19:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.124.138 with HTTP; Tue, 12 Sep 2017 07:19:01 -0700 (PDT) In-Reply-To: References: <1504863243.15735.13.camel@tropicalstormsoftware.com> <1504864640.15735.14.camel@tropicalstormsoftware.com> <1505208906.15735.24.camel@tropicalstormsoftware.com> From: Stan Ratliff Date: Tue, 12 Sep 2017 10:19:01 -0400 Message-ID: To: Henning Rogge Cc: Rick Taylor , "manet@ietf.org" Content-Type: multipart/alternative; boundary="089e08230ea49c659c0558feb901" Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 14:19:06 -0000 --089e08230ea49c659c0558feb901 Content-Type: text/plain; charset="UTF-8" On Tue, Sep 12, 2017 at 10:12 AM, Henning Rogge wrote: > On Tue, Sep 12, 2017 at 4:08 PM, Stan Ratliff > wrote: > > On Tue, Sep 12, 2017 at 10:04 AM, Henning Rogge > wrote: > >> What happens if one of my bridged routers uses a locally administrated > >> address as a MAC too? > > > > A couple of questions there - first, why would the bridged router not use > > the burned-in MAC? Secondly, if you're using randomly-generated suffixes > for > > the LAAs, then your chance of collision is very small. > > Either we should say "LID is a 'virtual MAC' and DLEP must make sure > not to collide"... or it is not a MAC and from a different namespace > and we should not care. > > The same train of thoughts made me think about extending the LID to 16 > bytes to make it really different (and make it easy to use all kind of > input including IPv6 addresses to generate them). > > That's a fair observation. In that case, I'd lobby for the first option - that is, a LID is a 'virtual MAC'. My rationale is this: A LID is a 'place where traffic goes'. It has metrics associated with it. Almost by definition, it has subnets (or maybe just 1 subnet) attached to it. Therefore, to me at least, it's a DLEP Destination. Perhaps we could split hairs and call it a 'sub-destination', in that multiple LIDs to the same radio will produce outgoing frames with the same DMAC address, but for all intents and purposes, it's a destination. Regards, Stan --089e08230ea49c659c0558feb901 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 12, 2017 at 10:12 AM, Henning Rogge <<= a href=3D"mailto:hrogge@gmail.com" target=3D"_blank">hrogge@gmail.com&g= t; wrote:
On Tue, Sep 12, 2017 at = 4:08 PM, Stan Ratliff <ratliffs= tan@gmail.com> wrote:
> On Tue, Sep 12, 2017 at 10:04 AM, Henning Rogge <hrogge@gmail.com> wrote:
>> What happens if one of my bridged routers uses a locally administr= ated
>> address as a MAC too?
>
> A couple of questions there - first, why would the bridged router not = use
> the burned-in MAC? Secondly, if you're using randomly-generated su= ffixes for
> the LAAs, then your chance of collision is very small.

Either we should say "LID is a 'virtual MAC' and DLEP must mak= e sure
not to collide"... or it is not a MAC and from a different namespace and we should not care.

The same train of thoughts made me think about extending the LID to 16
bytes to make it really different (and make it easy to use all kind of
input including IPv6 addresses to generate them).

That's a f= air observation. In that case, I'd lobby for the first option - that is= , a LID is a 'virtual MAC'.=C2=A0

My ratio= nale is this:
A LID is a 'place where traffic goes'. It h= as metrics associated with it. Almost by definition, it has subnets (or may= be just 1 subnet) attached to it. Therefore, to me at least, it's a DLE= P Destination.=C2=A0
Perhaps we could split hairs and call it a &= #39;sub-destination', in that multiple LIDs to the same radio will prod= uce outgoing frames with the same DMAC address, but for all intents and pur= poses, it's a destination.

Regards,
= Stan=C2=A0

--089e08230ea49c659c0558feb901-- From nobody Tue Sep 12 09:47:38 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B651213306B for ; Tue, 12 Sep 2017 09:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 7BljhY9FJvgP for ; Tue, 12 Sep 2017 09:47:35 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD747132403 for ; Tue, 12 Sep 2017 09:47:33 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 12 Sep 2017 17:47:06 +0100 From: Rick Taylor To: "ratliffstan@gmail.com" , "hrogge@gmail.com" CC: "manet@ietf.org" Thread-Topic: [manet] Thoughts on draft-dlep-lid Thread-Index: AQHTKIZj53J9/AH/OUGjxC7M5WHHyKKqr+gAgABVuYCABD6cgIAAhBPWgAEqtQCAACG7AIAAKVmAgAAAT4CAAAELgIAAAQiAgAAB3YCAACjpAA== Date: Tue, 12 Sep 2017 16:45:26 +0000 Message-ID: <1505234726.15735.43.camel@tropicalstormsoftware.com> References: <1504863243.15735.13.camel@tropicalstormsoftware.com> <1504864640.15735.14.camel@tropicalstormsoftware.com> <1505208906.15735.24.camel@tropicalstormsoftware.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 16:47:37 -0000 T24gVHVlLCAyMDE3LTA5LTEyIGF0IDEwOjE5IC0wNDAwLCBTdGFuIFJhdGxpZmYgd3JvdGU6DQo+ IA0KPiANCj4gT24gVHVlLCBTZXAgMTIsIDIwMTcgYXQgMTA6MTIgQU0sIEhlbm5pbmcgUm9nZ2Ug PGhyb2dnZUBnbWFpbC5jb20+DQo+IHdyb3RlOg0KPiA+IE9uIFR1ZSwgU2VwIDEyLCAyMDE3IGF0 IDQ6MDggUE0sIFN0YW4gUmF0bGlmZiA8cmF0bGlmZnN0YW5AZ21haWwuY28NCj4gPiBtPiB3cm90 ZToNCj4gPiA+IE9uIFR1ZSwgU2VwIDEyLCAyMDE3IGF0IDEwOjA0IEFNLCBIZW5uaW5nIFJvZ2dl IDxocm9nZ2VAZ21haWwuY29tDQo+ID4gPiB3cm90ZToNCj4gPiA+PiBXaGF0IGhhcHBlbnMgaWYg b25lIG9mIG15IGJyaWRnZWQgcm91dGVycyB1c2VzIGEgbG9jYWxseQ0KPiA+IGFkbWluaXN0cmF0 ZWQNCj4gPiA+PiBhZGRyZXNzIGFzIGEgTUFDIHRvbz8NCj4gPiA+DQo+ID4gPiBBIGNvdXBsZSBv ZiBxdWVzdGlvbnMgdGhlcmUgLSBmaXJzdCwgd2h5IHdvdWxkIHRoZSBicmlkZ2VkIHJvdXRlcg0K PiA+IG5vdCB1c2UNCj4gPiA+IHRoZSBidXJuZWQtaW4gTUFDPyBTZWNvbmRseSwgaWYgeW91J3Jl IHVzaW5nIHJhbmRvbWx5LWdlbmVyYXRlZA0KPiA+IHN1ZmZpeGVzIGZvcg0KPiA+ID4gdGhlIExB QXMsIHRoZW4geW91ciBjaGFuY2Ugb2YgY29sbGlzaW9uIGlzIHZlcnkgc21hbGwuDQo+ID4gDQo+ ID4gRWl0aGVyIHdlIHNob3VsZCBzYXkgIkxJRCBpcyBhICd2aXJ0dWFsIE1BQycgYW5kIERMRVAg bXVzdCBtYWtlDQo+ID4gc3VyZQ0KPiA+IG5vdCB0byBjb2xsaWRlIi4uLiBvciBpdCBpcyBub3Qg YSBNQUMgYW5kIGZyb20gYSBkaWZmZXJlbnQNCj4gPiBuYW1lc3BhY2UNCj4gPiBhbmQgd2Ugc2hv dWxkIG5vdCBjYXJlLg0KPiA+IA0KPiA+IFRoZSBzYW1lIHRyYWluIG9mIHRob3VnaHRzIG1hZGUg bWUgdGhpbmsgYWJvdXQgZXh0ZW5kaW5nIHRoZSBMSUQgdG8NCj4gPiAxNg0KPiA+IGJ5dGVzIHRv IG1ha2UgaXQgcmVhbGx5IGRpZmZlcmVudCAoYW5kIG1ha2UgaXQgZWFzeSB0byB1c2UgYWxsIGtp bmQNCj4gPiBvZg0KPiA+IGlucHV0IGluY2x1ZGluZyBJUHY2IGFkZHJlc3NlcyB0byBnZW5lcmF0 ZSB0aGVtKS4NCj4gPiANCj4gPiANCj4gDQo+IFRoYXQncyBhIGZhaXIgb2JzZXJ2YXRpb24uIElu IHRoYXQgY2FzZSwgSSdkIGxvYmJ5IGZvciB0aGUgZmlyc3QNCj4gb3B0aW9uIC0gdGhhdCBpcywg YSBMSUQgaXMgYSAndmlydHVhbCBNQUMnLsKgDQo+IA0KPiBNeSByYXRpb25hbGUgaXMgdGhpczoN Cj4gQSBMSUQgaXMgYSAncGxhY2Ugd2hlcmUgdHJhZmZpYyBnb2VzJy4gSXQgaGFzIG1ldHJpY3Mg YXNzb2NpYXRlZCB3aXRoDQo+IGl0LiBBbG1vc3QgYnkgZGVmaW5pdGlvbiwgaXQgaGFzIHN1Ym5l dHMgKG9yIG1heWJlIGp1c3QgMSBzdWJuZXQpDQo+IGF0dGFjaGVkIHRvIGl0LiBUaGVyZWZvcmUs IHRvIG1lIGF0IGxlYXN0LCBpdCdzIGEgRExFUCBEZXN0aW5hdGlvbi7CoA0KPiBQZXJoYXBzIHdl IGNvdWxkIHNwbGl0IGhhaXJzIGFuZCBjYWxsIGl0IGEgJ3N1Yi1kZXN0aW5hdGlvbicsIGluIHRo YXQNCj4gbXVsdGlwbGUgTElEcyB0byB0aGUgc2FtZSByYWRpbyB3aWxsIHByb2R1Y2Ugb3V0Z29p bmcgZnJhbWVzIHdpdGggdGhlDQo+IHNhbWUgRE1BQyBhZGRyZXNzLCBidXQgZm9yIGFsbCBpbnRl bnRzIGFuZCBwdXJwb3NlcywgaXQncyBhDQo+IGRlc3RpbmF0aW9uLg0KDQpJJ20gd2l0aCBTdGFu IG9uIHRoaXM6ICBBIExJRCBpcyBqdXN0IGFuIG9wYXF1ZSBpZGVudGlmaWVyIG9mDQonc29tZXdo ZXJlIHdpdGggYW4gSVAgYWRkcmVzcyBhbmQgc3VibmV0JyB0aGF0IGhhcHBlbnMgdG8gYmUgc2Ft ZQ0KbGVuZ3RoIGFzIGEgTUFDLCBwdXJlbHkgZm9yIGNvbnZlbmllbmNlLiAgWWVzLCBpdCdzIGEg ZGVzdGluYXRpb24sIGl0DQpqdXN0IGRvZXNuJ3QgaGFwcGVuIHRvIGhhdmUgYW4gJ290aGVyIGVu ZCcgd2l0aCBhIHVzYWJsZSBNQUMgYWRkcmVzcy4NCg0KR2l2ZW4gdGhlIGFtb3VudCBvZiBjb25m dXNpb24gbWFraW5nIHRoZW0gbG9vayBsaWtlIE1BQ3MgY2F1c2VzLCBJJ20NCnRoaW5raW5nIGFi b3V0IGNoYW5naW5nIHRvIDEgY2FwaXRhbCBsZXR0ZXIgW0EtWl0gb25seS4gIElmIHlvdSBuZWVk DQptb3JlIHRoYXQgMjYgTElEcyBwZXIgc2Vzc2lvbiB0aGVuIHlvdSdyZSB1c2luZyB0aGUgd3Jv bmcgdGVjaG5vbG9neS4NCg0KVGhlIG1haW4gYWR2YW50YWdlIG9mIHVzaW5nIDYgb3IgOCBvY3Rl dHMgZm9yIHlvdXIgSUQgaXMgdGhhdCB5b3UgQ09VTEQNCmRlcml2ZSBpdCBmcm9tIHNvbWUgaW50 ZXJuYWwgbGluay1sYXllciBNQUMsIG9yIGp1c3Qgc3RhcnQgY291bnRpbmcNCmZyb20gMS4NCg0K Umljaw0K From nobody Tue Sep 12 09:50:38 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3FC133091 for ; Tue, 12 Sep 2017 09:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 duGtXKQ9g_Us for ; Tue, 12 Sep 2017 09:50:35 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694AA132403 for ; Tue, 12 Sep 2017 09:50:33 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 12 Sep 2017 17:50:06 +0100 From: Rick Taylor To: "ratliffstan@gmail.com" , "hrogge@gmail.com" CC: "manet@ietf.org" Thread-Topic: [manet] Thoughts on draft-dlep-lid Thread-Index: AQHTKIZj53J9/AH/OUGjxC7M5WHHyKKqr+gAgABVuYCABD6cgIAAhBPWgAEqtQCAACG7AIAAKVmAgAAuEQA= Date: Tue, 12 Sep 2017 16:48:42 +0000 Message-ID: <1505234922.15735.47.camel@tropicalstormsoftware.com> References: <1504863243.15735.13.camel@tropicalstormsoftware.com> <1504864640.15735.14.camel@tropicalstormsoftware.com> <1505208906.15735.24.camel@tropicalstormsoftware.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <0fa68b79-2682-4b8b-aaa2-e454956c3c5b> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 16:50:37 -0000 T24gVHVlLCAyMDE3LTA5LTEyIGF0IDEwOjAzIC0wNDAwLCBTdGFuIFJhdGxpZmYgd3JvdGU6DQo+ IA0KPiANCj4gT24gVHVlLCBTZXAgMTIsIDIwMTcgYXQgNzozNSBBTSwgSGVubmluZyBSb2dnZSA8 aHJvZ2dlQGdtYWlsLmNvbT4NCj4gd3JvdGU6DQo+ID4gT24gVHVlLCBTZXAgMTIsIDIwMTcgYXQg MTE6MzUgQU0sIFJpY2sgVGF5bG9yDQo+ID4gPHJpY2tAdHJvcGljYWxzdG9ybXNvZnR3YXJlLmNv bT4gd3JvdGU6DQo+ID4gPiBTb3JyeSwgSSB3YXMgYXdheSBmcm9tIG15IG1hY2hpbmUgeWVzdGVy ZGF5LMKgIGNvbW1lbnRzIGlubGluZS4uLg0KPiA+ID4NCj4gPiA+IE9uIE1vbiwgMjAxNy0wOS0x MSBhdCAxNjo0NSArMDIwMCwgSGVubmluZyBSb2dnZSB3cm90ZToNCj4gPiA+PiBJIHdvdWxkIHN1 Z2dlc3Qgc2V0dGluZyBhIGZpeGVkIGxlbmd0aCBmb3IgdGhlIExJRCB0b28uLi4NCj4gPiA+DQo+ ID4gPiBFeGNlbGxlbnQsIHRoaXMgbWlycm9ycyB0aGUgZWFybGllciBkaXNjdXNzaW9uLCB3aGVy ZSB3ZQ0KPiA+IGNvbmNsdWRlZCB0aGF0DQo+ID4gPiBhIGZpeGVkIGxlbmd0aCBMSUQgaXMgdGhl IGJlc3QgY29tcHJvbWlzZS4NCj4gPiANCj4gPiBZZXMuDQo+ID4gDQo+ID4gPiBBZnRlciBkaXNj dXNzaW9uLCB0aGUgY29uY2x1c2lvbiB3YXMgb3B0aW9uIGQgd2FzIHRoZSBiZXN0DQo+ID4gY29t cHJvbWlzZSwNCj4gPiA+IGFuZCBpcyB3aGF0IGlzIGRlc2NyaWJlZCBpbiBkcmFmdC1kbGVwLWxp ZC0wMSAod2hpY2ggaXMgYW4NCj4gPiBpbmNvcnJlY3QNCj4gPiA+IG5hbWUgSSBjb3VsZCBmaXgs IGJ1dCBJJ20gaG9waW5nIHRvIHJlbmFtZSBhcyBkcmFmdC1tYW5ldC1kbGVwLQ0KPiA+IGxpZC0w MCkNCj4gPiANCj4gPiBJIHdhcyB0aGlzIG9waW5pb24gdG9vLCBidXQgSSB0aGluayB0aGVyZSBh cmUgZGlzYWR2YW50YWdlcyBpbg0KPiA+IGNob29zaW5nIHRoZSBzYW1lIGxlbmd0aC4uLiBpbmNs dWRpbmcgdGhlIHByb2JsZW0gb2YgbWl4aW5nIHRoZW0gdXANCj4gPiB3aXRoIE1BQyBhZGRyZXNz ZXMgKGFuZCB0aGUgcXVlc3Rpb24gaWYgeW91IGFyZSBhbGxvd2VkIHRvIGNob29zZSBhDQo+ID4g TElEIHRoYXQgaXMgYWxzbyBiZSB1c2VkIGFzIGEgTUFDIGFkZHJlc3MpLg0KPiANCj4gQXMgZm9y IGNob29zaW5nIGEgTElEIHRoYXQgaXMgYWxzbyBhIE1BQyAtIEknZCBzYXkgYW4gZW1waGF0aWMg bm8uDQo+IE9uZSBzY2hlbWUgaXMgdG8gbWFyayB0aGUgTElEcyBhcyBMb2NhbGx5IEFkbWluaXN0 ZXJlZCBBZGRyZXNzZXMuDQo+IFRoZXkncmUgZ3VhcmFudGVlZCBub3QgdG8gY2xhc2ggd2l0aCBy ZWFsIE1BQyBhZGRyZXNzZXMuIMKgwqANCg0KSSdtIG9wcG9zZWQgdG8gbWFraW5nIGFueSBzb3J0 IG9mIE1BQy1saWtlIGNvbW1lbnQsIHN1Y2ggYXMgIlVzZSB0aGUNCkxvY2FsbHkgQWRtaW5pc3Rl cmVkIGJpdCIgYWJvdXQgTElEcyBhcyBpdCBpbXBsaWVzIHRoYXQgdGhleSBhcmUgaW4NCnNvbWUg dW5zcGVjaWZpZWQgd2F5IE1BQ3MsIGFuZCB0aGV5J3JlIG5vdDoganVzdCBudW1iZXJzIGluIHRo ZSByYW5nZQ0KWzAuLjJeNDgpDQoNClJpY2s= From nobody Wed Sep 13 23:54:39 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7F81321D8 for ; Wed, 13 Sep 2017 23:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 U-5sI90gJ3RC for ; Wed, 13 Sep 2017 23:54:37 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27F211321A2 for ; Wed, 13 Sep 2017 23:54:37 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id b82so5388070qkc.4 for ; Wed, 13 Sep 2017 23:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=awCwZOgbjy0Ei+5gDRskbQhDAzj5FEekexfp9T7nVqA=; b=dwhDq/UiKo8Nmj5uRvdsPC62APv5iVgrSWzfAtSfTx6pfBeaQWemBtN8VDDqAOx2Eo Wcm+WMXJ0/sgrTTZC+Qnlkx3aQYDxj8WsldbQ4KuET7Bcpsq0b8aBIi5bug+xYC2cKt/ b0sLfgvmSkw133SyRJtZLlYsCdLCujpZYt9U7sLkcXZjJBw6oglLfSkacYR/6jT85akD 3Uw9nb9t+H1AhP+czeuhq3TjMW74MJR0T0/zZz2x1652oHOdy3hQ5Oc1gydlX8/1DJP6 FoHVYtS4g7n4XTpyM+TcB3Cj8jkeV4bE1ISHNRo2Gv1KSTBHVmcE7/1PUHmLvEDoIMZj DLKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=awCwZOgbjy0Ei+5gDRskbQhDAzj5FEekexfp9T7nVqA=; b=MC51u6umndXchnyXYbaxKAkiDtRypNf55AOFf7j+a2ogCblmkAliJlOsZ9GPQv7npQ W8ilvTfFytBCEM2yu91cO005GB4y52hRruQ3F+is2wZwAIoT4sKHUYdkArB2XhAsssaW GJzNnkS7zqu+zcVziUMWaaoKssvEQnOwOJnGWQkN4I5jQWRVH1YBHK6mlHjIEj1YGhZt MowEueSmhKc/OTLH6LfeZapBVflPPYRYbEpoLam865sP4zFnfk6zlqpze91bW98qgJex LYLooWP/otPrRk7vTqvqcWNoMFW/zS2HAhJRSz+/+PwQHDWiaClCQry+NbXgkujh4sRX UdQQ== X-Gm-Message-State: AHPjjUg4zL6dauLN64Lb4KFoZexIbRwzSO35M4YNCob0OFH/yHgOS4y5 P+aCW6RM+QoFS71QYMw29EJvBNiqo4+2DEayjkQ= X-Google-Smtp-Source: AOwi7QBbl4Xtxn36l0SznNcAtEk/uZo4612reVsVRskq8fF/JSzaeZROfrsDguOqwdIEW64tI2JEfSq97Z82S5HZC40= X-Received: by 10.55.122.130 with SMTP id v124mr1364678qkc.209.1505372076183; Wed, 13 Sep 2017 23:54:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.50.229 with HTTP; Wed, 13 Sep 2017 23:54:05 -0700 (PDT) In-Reply-To: <1505234922.15735.47.camel@tropicalstormsoftware.com> References: <1504863243.15735.13.camel@tropicalstormsoftware.com> <1504864640.15735.14.camel@tropicalstormsoftware.com> <1505208906.15735.24.camel@tropicalstormsoftware.com> <1505234922.15735.47.camel@tropicalstormsoftware.com> From: Henning Rogge Date: Thu, 14 Sep 2017 08:54:05 +0200 Message-ID: To: Rick Taylor Cc: "ratliffstan@gmail.com" , "manet@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 06:54:38 -0000 On Tue, Sep 12, 2017 at 6:48 PM, Rick Taylor wrote: > I'm opposed to making any sort of MAC-like comment, such as "Use the > Locally Administered bit" about LIDs as it implies that they are in > some unspecified way MACs, and they're not: just numbers in the range > [0..2^48) If they are totally independent from MACs, why not give them a few more bytes... it will prevent people from making the (easy) mistake to think they don't collide with the used MACs... and it is still trivial to use MACs (or IPv4 or IPv6) as a source for the ID. Henning From nobody Thu Sep 14 06:05:14 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D21212008A for ; Thu, 14 Sep 2017 06:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 s7TYstCjtYyh for ; Thu, 14 Sep 2017 06:05:10 -0700 (PDT) Received: from smtp.iit.cnr.it (mx4.iit.cnr.it [146.48.98.151]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9E0132F65 for ; Thu, 14 Sep 2017 06:05:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id BBD03B80716 for ; Thu, 14 Sep 2017 15:05:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mx4.iit.cnr.it Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx4.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7LjHa9ab_3R for ; Thu, 14 Sep 2017 15:05:01 +0200 (CEST) Received: from turig.iit.cnr.it (turig.iit.cnr.it [146.48.98.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.iit.cnr.it (Postfix) with ESMTPSA id 35C3FB80188 for ; Thu, 14 Sep 2017 15:05:01 +0200 (CEST) DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.iit.cnr.it 35C3FB80188 Authentication-Results: smtp.iit.cnr.it; dmarc=none header.from=iit.cnr.it Date: Thu, 14 Sep 2017 15:05:01 +0200 From: Elisabetta Biondi To: manet@ietf.org Message-ID: <59ba7e7d.r9npbOy5AlyZdxce%e.biondi@iit.cnr.it> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [manet] Special Issue on Information and Opinion Diffusion in Online Social Networks and Media X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 13:05:12 -0000 CALL FOR PAPERS Elsevier - Online Social Networks and Media Journal Special Issue on Information and Opinion Diffusion in Online Social Networks and Media Submission Deadline: October 1st, 2017 http://www.journals.elsevier.com/online-social-networks-and-media/ Online Social Networks are a massively successful phenomenon, used by billions of users to interact. Nowadays, information diffusion in Online Social Networks and Media (OSNEM) has a major role, among many others, for recommendation systems, advertising, and political campaigns. Moverover, the way information circulates in OSNEM impacts on the formation of opinions and on the social roles of users and their influence on others. OSNEM are extensively used for spreading information, opinions and ideas, but also to propagate fake news and rumors. Therefore, prevention of spam, bots and fake accounts, information leakage, trustworthiness of information and trust between users are relevant research issues associated with information diffusion. This special issue seeks contributions pushing the state of the art in all facets of information and opinion diffusion in online social networks and media. We solicit manuscripts where quantitative and/or data-driven approach is used to investigate information and opinion diffusion in OSNEM. Topics include, but are not limited to: - Dynamics of trends, information and opinion diffusion in OSNEM - Recommendations and advertising in OSNEM - Spread of news, topics, and opinions - Trust, reputation, privacy in OSNEM information and opinion diffusion - Rumors and fake news spreading in OSNEM - Bots and fake users detection - Influence analysis and social influence - Identification of diffusion sources and influencers - Methods to modify/control/maximise information and opinion diffusion - Measurements of information and opinion diffusion??in OSNEM - Models of information and opinion diffusion - Data-driven approaches to study information and opinion diffusion in OSNEM *** Tentative Schedule *** Manuscript submission deadline: October 1, 2017 First notification: November 10, 2017 Submission of revised paper: December 10, 2017 Notification of acceptance: January 10, 2018 Guest Editors Marco Conti, IIT-CNR, Italy Andrea Passarella, IIT-CNR, Italy *** Instructions for submission *** Manuscripts must not have been previously published nor currently under review by other journals or conferences. Papers previously published in conference proceedings are eligible for submission if the submitted manuscript is a substantial revision and extension of the conference version. In this case, authors should indicate the previous publication(s) in the cover letter and are also required to submit their published conference article(s) and a summary document explaining the enhancements made in the journal version. The submission website for this journal is located at https://www.evise.com/profile/#/OSNEM/login. Please select "Research Paper" when you reach the "Article Type" step in the submission process. To ensure that all manuscripts are correctly identified, for consideration by the special issue, the authors should indicate in the cover letter that the manuscript has been submitted for the special issue on Information and Opinion Diffusion in Online Social Networks and Media. For further information, please contact the guest editors at {m.conti,a.passarella} at iit.cnr.it From nobody Mon Sep 18 23:48:37 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0268F133023 for ; Mon, 18 Sep 2017 23:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OBaM5tblEAu5 for ; Mon, 18 Sep 2017 23:48:34 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88A47126E64 for ; Mon, 18 Sep 2017 23:48:34 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id b23so2718275qkg.1 for ; Mon, 18 Sep 2017 23:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+IyL9X56S9G2hQUb0LiObDIlzV1iCwK8iUsb3t4bQD8=; b=Yd8Tj5G0RcJihAGbCP2TaQoA50mDKbgoycG+0dL/gd+atiQegouBwxQcD8/IIqnHaJ ZPFYpxyEVyiR7ZDPUc76WyB/jVe4Rxdi8nN8kcd65q8EirOFDDZWChtWOSvlcKn2lTAD Y3Pm/L+SuM1YDCHlJvzoz7U9iEgouKxoYLp93868lmns5YvtZpeJ64OZWtU6N5ZWP5P2 UgrPej7RfhgHp3iAGE0GhO0wEMopH+/gkYkORh/RaNtYFPitFj1Mj6RduFwgf4J0RW3h 65hQeuNXIpEmfKkCy0jScYcZVBjbb0WVHIY810+/vnkE2CZYgwZThhd+FTOCFOMuQpu6 RcHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+IyL9X56S9G2hQUb0LiObDIlzV1iCwK8iUsb3t4bQD8=; b=VEk+DxaIdqKl0FxH+DrIooFyeeendv4458S+kYkMvNptCMn8K1DuDTpBXwCrA1czPG qBB/nVyjMO8XcyUU+0xIfc8RMn/urJGFZdN00WZbDhbw7h6HYRaxeA3mrewxqNjLcBjn qKPxtr117yPcb/WEEw63QDSbcu8JR8Gm+QOZmdKMZHvGMyutd5fgYLbHRn71WbaNALHM 7589QdghJJ2bLifzVfADLb0jQA9mjaWzMKFOYeYj3e3apZ9wiFLHHrSbgu6pPj1YTSKd RdZDhI+VbFQPpV3iO7w9w1SViXbhTd6Scdy/gIGh9gHG46h7fd5yM4N7m2nlrbq+3Dfn ZryA== X-Gm-Message-State: AHPjjUjg66c+Wq7Mba9fS+lIST6Qjyq8ulT843hJek6SbKG60x/Gb5tc UsHp47yjT0OOqCqtmWsXDOW+AVUd/1z2vWpGPT0= X-Google-Smtp-Source: AOwi7QCmsDQH/r7Y7XR+IhszxH2sZ8cy8CQo7GWTzUAV4vb6HulPZgCyZrHt2OxMZ0kpQ7iiTS360xjR+PRe0ykLTq4= X-Received: by 10.233.239.69 with SMTP id d66mr529288qkg.296.1505803713439; Mon, 18 Sep 2017 23:48:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.50.229 with HTTP; Mon, 18 Sep 2017 23:48:02 -0700 (PDT) In-Reply-To: References: <1504863243.15735.13.camel@tropicalstormsoftware.com> <1504864640.15735.14.camel@tropicalstormsoftware.com> <1505208906.15735.24.camel@tropicalstormsoftware.com> <1505234922.15735.47.camel@tropicalstormsoftware.com> From: Henning Rogge Date: Tue, 19 Sep 2017 08:48:02 +0200 Message-ID: To: Rick Taylor Cc: "ratliffstan@gmail.com" , "manet@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 06:48:36 -0000 I will try to summarize the 'three' solutions we had on this thread in the last weeks: 1) make LID a 6/8 byte identifier independent from MAC addresses (they can have the same binary value than an used MAC) 2) make LID a 6/8 byte identifier which MUST NOT collide with an used MAC address 3) make LID a 16 byte identifier In my opinion case 2) means that we call LIDs something like "virtual MAC" or "local generated MAC"... if they use the same 'namespace' and must not collide, we should make sure that the protocol designers and protocol users know they are from the same namespace. At the moment Rick proposes 1), Stan proposes 2) and I proposes 3)... What shall we do? Henning From nobody Tue Sep 19 07:12:23 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D4C134338 for ; Tue, 19 Sep 2017 07:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 llh_dq67LpwA for ; Tue, 19 Sep 2017 07:12:15 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86C3C1331E3 for ; Tue, 19 Sep 2017 07:12:15 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id c195so115567itb.1 for ; Tue, 19 Sep 2017 07:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SyNsEEt4LUanjlLS6y3usJ60iK6Y1iznNX8RKFZdW6k=; b=cGnMo1Gr47DrBNIr+Wo4AxANnj8wUOwigpTTWNQ+1jrusuXqy2Yt/tOiZLKmz9ZDn5 fI/DlvhaChhsWKULSpexcmJJBjRb1Cxf7xxWwncHrth62svcMB47sJVZgV3Ryg2FAlQe 8m2wzBHOywakiqUqZcZrnRy8XOboqTprEA0MmogFKadKn4fNBH9kv0M8x0pATovDFMnx Z25aaTtDtb/sbeO226cszEzIxJUiW6lCIB5DmqcpPP+GphPkS4xRF8ChtB+JqZMpgwPl Y/4XUe2/7ssiwbgVMCSoNSYv326oDZkE/GFvaAzOv+7ROFWbqJBv+b2vBPOgREJz7gfa i+ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SyNsEEt4LUanjlLS6y3usJ60iK6Y1iznNX8RKFZdW6k=; b=GkTAhYz6Vc83hqC62csN7pcVfsjUJ5uQVMoyMv2TFIUICbJHwrZN1SBi3fBEYKonwN OVA7tWHC2Mlcfk9uIxAvOxUNfIm7dVoarAnWooXSEQNqeAZN/v9CFcS8qv4zuJLGRKn1 IZ85KTo2VDY3GBOsyLBpCnbMUJzbsKy5+XLEFx6qq2A9gARIskw3P6oL96dMLcMyQ4Tm St82JUlssnuBVHslVhxswizVj9DcsiSXFqGv6KW8z3/xLQ4RpK29bc8WF/6j9I93fXi+ W25Gki08KZe/G9jmFyfqWt1iE9o3OTmqFYeQxzLgfNerqfXXcoxmF1GxGNGnyqMFrWDE EEjQ== X-Gm-Message-State: AHPjjUi38cVvMgEgq76hyn11aHvvWel11/8EemX4vqaYs9qhCONdGJjE iTVwfANZJUfzi/2gwFXlBKJ/35k0Kl6TVF6QvSA= X-Google-Smtp-Source: AOwi7QBRI2hwX7Wy9RA+XLAkesCeT6Mmcl874RuGCy93Hl1vCmvOr7RrQyEzsPHOQcCp6aw+cHdshY/6i0S1ZgFl8hg= X-Received: by 10.36.177.9 with SMTP id o9mr1905565itf.44.1505830334642; Tue, 19 Sep 2017 07:12:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.124.138 with HTTP; Tue, 19 Sep 2017 07:12:13 -0700 (PDT) In-Reply-To: References: <1504863243.15735.13.camel@tropicalstormsoftware.com> <1504864640.15735.14.camel@tropicalstormsoftware.com> <1505208906.15735.24.camel@tropicalstormsoftware.com> <1505234922.15735.47.camel@tropicalstormsoftware.com> From: Stan Ratliff Date: Tue, 19 Sep 2017 10:12:13 -0400 Message-ID: To: Henning Rogge Cc: Rick Taylor , "manet@ietf.org" Content-Type: multipart/alternative; boundary="089e08230ea43044c605598b72d1" Archived-At: Subject: Re: [manet] Thoughts on draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 14:12:18 -0000 --089e08230ea43044c605598b72d1 Content-Type: text/plain; charset="UTF-8" Henning, On Tue, Sep 19, 2017 at 2:48 AM, Henning Rogge wrote: > I will try to summarize the 'three' solutions we had on this thread in > the last weeks: > > 1) make LID a 6/8 byte identifier independent from MAC addresses (they > can have the same binary value than an used MAC) > > 2) make LID a 6/8 byte identifier which MUST NOT collide with an used > MAC address > > 3) make LID a 16 byte identifier > > > In my opinion case 2) means that we call LIDs something like "virtual > MAC" or "local generated MAC"... if they use the same 'namespace' and > must not collide, we should make sure that the protocol designers and > protocol users know they are from the same namespace. > > At the moment Rick proposes 1), Stan proposes 2) and I proposes 3)... > > What shall we do? > > Henning > What a router would need from the modem's specification of a LID is that 1. The LID is unique, at least within the context of a single modem, and 2. The next hop (the MAC address) for traffic going to the LID 3. Subnets that are accessible via the LID. Any subnets attached to the LID would be inserted into the router's RIB with the next hop address. The issue I had with the initial draft is that the MAC address is inferred - it was just assumed that the MAC address used for forwarding traffic to the LID was the same as the MAC address the modem is using for the DLEP TCP session. I'd prefer it if the MAC address used for data plane forwarding is explicitly defined via the existing TLV. I understand that could create some issues - for instance, a modem announcing the presence of 4 LIDs might (or might not) want to replicate the same MAC address for all 4. We've currently created a protocol where MACs are guaranteed to be unique, but I think we can craft some text essentially saying "Well, yeah... but not in this case..." Now, for the length. I admittedly made something of a leap, in that it occurred to me that if LIDs are the same size as MAC addresses, and they don't clash with existing MACs, an implementation could easily put them into the existing DLEP information base, without much modification. But, I can see an implementation that uses some arbitrary LID length working as well - I just view that as more effort to implement. You'd need a "LID information base" that's hung off of the DLEP Peer. That's why I said earlier in the conversation that I can live with the notion that sizeof(LID) != sizeof(MAC). So, you could say that my proposal for sizeof(LID) == sizeof(MAC) is not a passionately-held position. Where I start to get passionate is in my belief that the MAC address used for traffic forwarding MUST be explicitly specified by the modem, and not inferred. Regards, Stan --089e08230ea43044c605598b72d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Henning,=C2=A0


On Tue, Sep 19, 2017 at = 2:48 AM, Henning Rogge <hrogge@gmail.com> wrote:
I will try to summarize the 'three' solutions= we had on this thread in
the last weeks:

1) make LID a 6/8 byte identifier independent from MAC addresses (they
can have the same binary value than an used MAC)

2) make LID a 6/8 byte identifier which MUST NOT collide with an used
MAC address

3) make LID a 16 byte identifier


In my opinion case 2) means that we call LIDs something like "virtual<= br> MAC" or "local generated MAC"... if they use the same 'n= amespace' and
must not collide, we should make sure that the protocol designers and
protocol users know they are from the same namespace.

At the moment Rick proposes 1), Stan proposes 2) and I proposes 3)...

What shall we do?

Henning

What a router wou= ld need from the modem's specification of a LID is that
1. Th= e LID is unique, at least within the context of a single modem, and=C2=A0
2. The next hop (the MAC address) for traffic going to the LID
3. Subnets that are accessible via the LID.

Any subnets attached to the LID would be inserted into the router's RI= B with the next hop address. The issue I had with the initial draft is that= the MAC address is inferred - it was just assumed that the MAC address use= d for forwarding traffic to the LID was the same as the MAC address the mod= em is using for the DLEP TCP session. I'd prefer it if the MAC address = used for data plane forwarding is explicitly defined via the existing TLV. = I understand that could create some issues - for instance, a modem announci= ng the presence of 4 LIDs might (or might not) want to replicate the same M= AC address for all 4. We've currently created a protocol where MACs are= guaranteed to be unique, but I think we can craft some text essentially sa= ying "Well, yeah... but not in this case..."
=C2=A0
Now, for the length. I admittedly made something of a leap, in that = it occurred to me that if LIDs are the same size as MAC addresses, and they= don't clash with existing MACs, an implementation could easily put the= m into the existing DLEP information base, without much modification. But, = I can see an implementation that uses some arbitrary LID length working as = well - I just view that as more effort to implement. You'd need a "= ;LID information base" that's hung off of the DLEP Peer. That'= s why I said earlier in the conversation that I can live with the notion th= at sizeof(LID) !=3D sizeof(MAC).=C2=A0

So, you cou= ld say that my proposal for sizeof(LID) =3D=3D sizeof(MAC) is not a passion= ately-held position. Where I start to get passionate is in my belief that t= he MAC address used for traffic forwarding MUST be explicitly specified by = the modem, and not inferred.=C2=A0

Regards,
<= div>Stan
--089e08230ea43044c605598b72d1--