Re: [Anima] Rtgdir last call review of draft-ietf-anima-autonomic-control-plane-24

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 10 April 2020 21:35 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2453A0DE5; Fri, 10 Apr 2020 14:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 n2RUyQzOGK0M; Fri, 10 Apr 2020 14:35:09 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 D10403A0DE3; Fri, 10 Apr 2020 14:35:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 48zWWd4cQ5z1p1sB; Fri, 10 Apr 2020 14:35:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1586554509; bh=xkIDquolfEgpaJ+Jw8RV8p9GqJIe7xZYza07lvKgX2Y=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ZEHWy6uWqODtfsti6XiwGhrBmmXz/nKUxE2xAs3NLj0lHnN3QR6wr/c1BC3KUuJQU dQCkSEyL/tM8R9RUyw+3sRov+rS9AKsupVeNFS5WBUY9Jtm9gUF9Q6m2LEsyK8hHRh EPG9aSpm+3V7BmsrDaJljcS5CB0bQf+eFlHE7LK4=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 48zWWc4FtJz1nt6j; Fri, 10 Apr 2020 14:35:08 -0700 (PDT)
To: Michael Richardson <mcr+ietf@sandelman.ca>, Brian E Carpenter <brian.e.carpenter@gmail.com>, rtg-dir@ietf.org, last-call@ietf.org, anima@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org
References: <158648497631.26678.9121665060210659827@ietfa.amsl.com> <1280ef73-a21c-63d9-3de9-2c4f7e68e10a@gmail.com> <709d4f5a-69a7-463e-07f3-b11cc3a9e70b@joelhalpern.com> <4750.1586554020@localhost>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <4908ff49-6db8-955b-faf3-26c840abefc6@joelhalpern.com>
Date: Fri, 10 Apr 2020 17:35:08 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <4750.1586554020@localhost>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/MiHY42eyfGv0ty5CztMonNgTxBA>
Subject: Re: [Anima] Rtgdir last call review of draft-ietf-anima-autonomic-control-plane-24
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Apr 2020 21:35:11 -0000

I am happy to propose some starting text (I am sure it will need further 
tuning) as a short definition of a Loopback Interface:
     Loopback Interface: A logical or virtual representation of
     connectivity for IP communication.  It is distinct from any
     physical interface on the device.  It is typically used to
     abstract a point of communication from any physical connectivity.

If we want to elaborate, we could not that this provides an interface to 
anchor IPv6 addresses in accordance with the IPv6 addressing architecture.

As for the L2 material, if the WG wants to remove it, I would be fine 
with that.  It is clearly supplementary.  I am just trying to avoid 
confusion if we choose to describe it.

Yours,
Joel


On 4/10/2020 5:27 PM, Michael Richardson wrote:
> 
> Joel M. Halpern <jmh@joelhalpern.com> wrote:
>      > On Loopback, I understand your frustration with the lack of a good
>      > definition.  Given that IPv6 addressing architecture constraints, you need
>      > some sort of interface.  In practice, the way loopbacks are used seems to
>      > match the need.  So I do not object to the usage.  just to the definition.
>      > It would also be acceptable to simply craft a different term and clearly
>      > define it if the usage is sufficiently different from existing
>      > practice.
> 
> Reading this thread, I was hoping you might be able to help us with a better
> definition then :-)
> 
> We are doing exactly what OSPF and BGP does operationally on every platform
> that I have every worked on.  We are just doing it with RPL.
> 
> To me, it's *SO* obvious that it goes without saying, so now we are asked to
> say it, and we get into trouble because nobody before us bothered to say it.
> 
>      > On the final minor comment, it was specifically about the section on L2
>      > devices.  Maybe something special is needed for the special case of a shared
>      > network that is also a border network.  But that seems very rare. And getting
>      > the L2 switch to do the right packet forwarding for the hybrid case seems an
>      > invitation to trouble.
> 
> I'm not happy about any of the L2 text; I would have left it out completely.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
> 
> 
>