Re: [lisp] Proposed WG Charter on GitHub

Dino Farinacci <farinacci@gmail.com> Fri, 06 October 2023 22:55 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA67CC151084; Fri, 6 Oct 2023 15:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.105
X-Spam-Level:
X-Spam-Status: No, score=-1.105 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, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAxEYdNyzfCi; Fri, 6 Oct 2023 15:55:16 -0700 (PDT)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44DDEC14CE54; Fri, 6 Oct 2023 15:55:16 -0700 (PDT)
Received: by mail-il1-x132.google.com with SMTP id e9e14a558f8ab-3512efed950so10666895ab.2; Fri, 06 Oct 2023 15:55:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696632915; x=1697237715; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=C2Ek0Kkxb1yM+IM0O7Ke8KRHGNs+a+SgiPTTDUGBZK4=; b=PWJz+FRZcvt7zlXtit3KpDsTI/XWu0FGF4QhduPaL7Ewk3pcfWDmAWRV4xjbBVKS2E 35Jq7+mrTd1jItHaQwcp6hIY1UOl/5dKRSD/jdJeQOoqggrTCD38X5ZwlR+DWZ3Wa+89 ZCbarZdCHPb3cHyZVNUpDSySeAUpnTBqnkMzWnssfaiXr730QCpxHIrs1fd/zl6QXvCq sLWN/AID0owelCjDXCjhrcpEc3ZQ4+8C4jZfYsXiW0dLXJ1FgF1MTm9J/XuqPXljkfaB qRyN5bSww3amkRmcqyAUAAlTzS0p0le7240svebXCXdkU0VRqMVLNjo1XzBFMBA3Tr6o +1HA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696632915; x=1697237715; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=C2Ek0Kkxb1yM+IM0O7Ke8KRHGNs+a+SgiPTTDUGBZK4=; b=NrgWiceJQFiOlma7nPxwXvmxZAPRNPCuHnrol5yzPHTYJhmOUKtY+bRwyWup7tKbm2 NvmCt1ZZZ5JHgNam/f1vnQ0M8JlVZzShOUgmfq8+Gkgz7J1aTMGNMuTKcVH5KxZeEHfh eIVAhIn3KdgwOyh+uY+x0RUEL0EkIXz89tY+fLI26AJrgKVAAFac7/QzzQm/54qySzgo aecDpRYy6AJCj8CP7NUym2ufIRjzNupQbl/FCmq2SdHei3NIwzib008W+svtbXPpoJIP YU52KmnNh4WJYL+V1IJz0ByfjIrziUycrrLXWm6YCs0SZUxMzh/fM8P4DA0FM7EV0DH9 VIPg==
X-Gm-Message-State: AOJu0YxPtesrzjB2FWd7y8Bq5VgHYw1obFI86hvW6KqTKhoA7MdnVoFK h/C2MDev6SEcs1yM4PtvPDo=
X-Google-Smtp-Source: AGHT+IHpdh5/W6BZvZL2oRCIpLf3ZJm1W2qLZgJ4vZ0OZiQT9BqXkUj/c4DAjJKgJ824uW7gRnQrKg==
X-Received: by 2002:a05:6e02:10d2:b0:351:5137:e89d with SMTP id s18-20020a056e0210d200b003515137e89dmr8123797ilj.27.1696632914990; Fri, 06 Oct 2023 15:55:14 -0700 (PDT)
Received: from smtpclient.apple ([75.104.86.179]) by smtp.gmail.com with ESMTPSA id q15-20020a02c8cf000000b0043cec02791bsm645136jao.96.2023.10.06.15.55.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Oct 2023 15:55:14 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <CAMMESsy46LBEmS539CM4BzHMVuX6TmrS1GQN3ssZkEs1jF60fg@mail.gmail.com>
Date: Fri, 06 Oct 2023 18:54:51 -0400
Cc: Padma Pillay-Esnault <padma.ietf@gmail.com>, LISP mailing list list <lisp@ietf.org>, lisp-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <C1FB78EB-EF2A-4956-92F3-D72548FD6309@gmail.com>
References: <CAG-CQxqkFVNq_wOFZuK7D6hEz__2mjtZkuu3Z=S-vBKxoJwdfw@mail.gmail.com> <CAMMESsy46LBEmS539CM4BzHMVuX6TmrS1GQN3ssZkEs1jF60fg@mail.gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
X-Mailer: Apple Mail (2.3731.700.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/8IrRMoZESn7pL7DbuakjyY3Epgo>
Subject: Re: [lisp] Proposed WG Charter on GitHub
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Oct 2023 22:55:20 -0000

Here are my comments. The charter text comes first and is indented and my comments follow:

> LISP Working Group Charter ProposalProposed Charter: Introduction
> LISP supports a routing architecture which decouples the routing locators and identifiers, thus allowing for efficient

"... supports an overlay routing …"

> aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP requires no changes to end-systems or to routers that do not directly participate in the LISP deployment. LISP aims for an incrementally deployable protocol, so new features and services can be added easily and quickly to the network using overlays. The scope of the LISP technology is potentially applicable to have a large span.The LISP WG is chartered to continue work on the LISP protocol and produce standard-track documents.

I would add some of the more explicit features that overlay routing can do and how LISP actually has done so and specified at a very detailed level. Some examples are mobility, VPNs, multicast, mix protocol family, all with the latest in security mechanisms.

> Proposed Charter: Work Items Part 1
>     • NAT-Traversal: Support for NAT-traversal solution in deployments where LISP tunnel routers are separated from correspondent tunnel routers by a NAT (e.g., LISP mobile node).
>     • YANG models for managing the LISP protocol and deployments that include data models, OAM, as well as allowing for programmable management interfaces. These management methods should be considered for both the data-plane, control plane, and mapping system components.
>     • Multicast Support: LISP support for multicast environments has a growing number of use cases. Support for multicast is needed in order to achieve scalability. The current documents [Ref to experimental multicast RFCs] should be merged and published as Standard Track.

I think the smaller work items that we can knock out should be in Part 1 like geo-coordinates and name-encoding. And there is no mention of VPN and TE support. It needs to go in somewhere.

> Proposed Charter: Work Items Part 2
>     • Standard Track Documents: The core specifications of LISP have been published as “Standard Track” [references]. The WG will continue the work of moving select specifications to “Standard Track”.
>     • Mobility: Some LISP deployment scenarios include mobile nodes (in mobile environments) or Virtual Machines (VMs in data centers), hence, support needs to be provided in order to achieve seamless connectivity.
>     • Privacy and Security: The WG will work on topics of EID anonymity, VPN segmentation leveraging on the Instance ID, and traffic anonymization. The reuse of existing mechanisms will be prioritized.

I would not call VPN segmentation as security. I view it more as topological member grouping.

>     • LISP Applicability: In time, LISP has proved to be a very flexible protocol that can be used in various use-cases not even considered during its design phase. RFC 7215, while remaining a good source of information, covers one single use case, which is not anymore the main LISP application scenario. The LISP WG will document LISP deployments for most recent and relevant use-cases so as to update RFC 7215.
> Proposed Charter: Tentative Milestones
>     • November 2023: Submit a LISP YANG document to the IESG for consideration
>     • March 2024: Submit a LISP NAT Traversal document to the IESG for consideration
>     • June 2024: Submit 8111bis to the IESG for consideration
>     • June 2024 : Submit LISP geo-coordinates for consideration

This, with name-encoding, can get done sooner. We just have to push harder.

>     • November 2024: Submit merged Multicast document to the IESG for consideration

Note, from the previous email you referred to "underlay-multicast-trees". That document has changed its name to reflect what it really is designing, its titled draft-vdas-lisp-group-mapping-00.

>     • March 2025: Submit 6832bis pXTRs to the IESG for consideration
>     • June 2025: Submit merged LCAFbis to the IESG for considerations
>     • November 2025: Submit LISP Mobile Node to the IESG for considerations
>     • March 2026: Submit LISP Applicability document to the IESG for considerations
>     • November 2026: Wrap-Up or recharter

There should be some mention on what to do with the use-case documents. Either a spin-off operational working group, or publish as Informational or something else.

And the same for draft-farinacci-lisp-decent, which is the only mapping database document on the table. I think its more than a operational use-case since there is design mechanisms and algorithms in the specification.

Dino

> On Oct 3, 2023, at 5:14 PM, Alvaro Retana <aretana.ietf@gmail.com> wrote:
> 
> Hi!
> 
> In general, I like the charter.  However, I have some questions/comments:
> 
> (1) What’s the difference between the work items in “Part 1” and the ones in “Part 2”?
> 
> (2) Related.  I’m assuming that the headers “Proposed Charter…” will be deleted.
> 
> (3) Multicast support. It’s not clear from the description if the work is just to merge the experimental RFCs or if there’s something else. ?
> 
> (4) LISP Applicability.  How will "the most recent and relevant use-cases” be determined?  I don’t think we need to answer, but the question may come up later in the process.
> 
> (5) Maybe reorder the work items to coincide with the order of the milestones.
> 
> (6) "LISP geo-coordinates” doesn’t map to a work item.
> 
> 
> I don’t have write access to the repo, so I’m attaching diffs with some editorial points.
> 
> 
> Thanks!
> 
> Alvaro.
> 
> On October 1, 2023 at 1:46:22 PM, Padma Pillay-Esnault (padma.ietf@gmail.com) wrote:
>> 
>> 
>> Hello all,
>> 
>> We have created a repository to gather input for the proposed LISP WG charter presented in our last meeting.
>> 
>> A pointer to the repo below
>> https://github.com/lisp-wg/wg-charter
>> 
>> We welcome your comments and contributions.
>> 
>> Thanks
>> Padma and Luigi
>> _______________________________________________ 
>> lisp mailing list 
>> lisp@ietf.org 
>> https://www.ietf.org/mailman/listinfo/lisp 
> <ad28c1db-4fd7-440d-acc8-eae8bbb99a7e.html>_______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp