From ggx@gigix.net Fri Oct 13 02:05:52 2023 Return-Path: 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 B2D04C151068 for ; Fri, 13 Oct 2023 02:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.908 X-Spam-Level: X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20230601.gappssmtp.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 LkNVKml99oGo for ; Fri, 13 Oct 2023 02:05:48 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 66BD9C14CE38 for ; Fri, 13 Oct 2023 02:05:43 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-5045cb9c091so2496351e87.3 for ; Fri, 13 Oct 2023 02:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20230601.gappssmtp.com; s=20230601; t=1697187940; x=1697792740; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=c6w94Y5Ca6RocFbQKmS/aEZMs6268sROqjOEQj91jak=; b=MCVzdmh/GO7vJSqvoJ21gloGxYci4bKWKGiMDIz54ltyeIAI5OG0eb2ElizAq2pQ0i xGy0cMDNPL6jNeJ75B3jBlgiRgAIfb7QrckZCs3QuLYwdLZsNQFS+AJUo8AG/pvhpJQ4 JZ0JCBTpPLigkgh8CzMc+jTYuaKwqubLFF2Y7ruhI4nrBTW6dFmpDT9JtS6R3nUd3BO8 nUnpPKhRuOqeUDn2NTEpaEcHDWsBpfK7elwb5gtrR2xz2Zu/2fHxEwfcNZc90OxYQXu1 HJd6Zw5VSTcOMogYhl9NijKggNyPBYN8AC5ZMZUfRlGQJp9uHcEcKJzU46HwU4kM2k25 tRCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697187940; x=1697792740; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=c6w94Y5Ca6RocFbQKmS/aEZMs6268sROqjOEQj91jak=; b=l9edAH+2bc85bJOQbeJcs3Cc+u4xrb8jlvBvHTQyz45tUGDpqJsJgJKfNGdEhqe44C gaN8GWOLi8GH6cH+BXbJqIDC+idXDFOtBl8Wx2g0wzHfD4L5qWUIHaA+5bc+qzXLmxj1 vYuW3lPA79MYzEVQSXcOuTwPgZWlErIWWA4BE0AwBVjVxv9Yhuha/NhJDi3e1eFSGZ9/ WXH5yqd4ZMNTqJATkJFuKM5BY3Z1+Qh0ljVaQ6GLYjvQAsaB3MWUCjIosvbYMICo57PN mwlikwxOLhWl2lS0bZr7Tc6dXdYco9X/3kMeHnczU4JZNkq7zR8xmCwefSACboGVVIzB E6+A== X-Gm-Message-State: AOJu0YzzPBQg8Vdsq+abrV1s/J/q4i/IYxgc6sKS/OeTeuT8XsQX7i5a w7ynvVjMXr+NsTfpc5eV/MTEvWgYcIjh6AroMSEj3g== X-Google-Smtp-Source: AGHT+IGXtxLEf4At7A1EQM1+RN5bI8aOGvuIBjWhY5fOECi4uRMJjUonK3BR8JkkgeLmufuXtTL9kw== X-Received: by 2002:a05:6512:280d:b0:503:a9c:af83 with SMTP id cf13-20020a056512280d00b005030a9caf83mr26074379lfb.41.1697187940103; Fri, 13 Oct 2023 02:05:40 -0700 (PDT) Received: from smtpclient.apple ([37.165.205.32]) by smtp.gmail.com with ESMTPSA id h19-20020a05600c261300b00405442edc69sm1947853wma.14.2023.10.13.02.05.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Oct 2023 02:05:39 -0700 (PDT) From: Luigi Iannone Message-Id: <7AA2F620-1223-4C17-A3D8-3F9D2AFEDBF5@gigix.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_7DDA0088-3CE8-4256-9E18-57462683480F" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.100.2.1.4\)) Date: Fri, 13 Oct 2023 11:05:28 +0200 In-Reply-To: Cc: "lisp-chairs@ietf.org" To: LISP mailing list list References: X-Mailer: Apple Mail (2.3774.100.2.1.4) Archived-At: Subject: [lisp] WG work items list [WAS: Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2023 09:05:52 -0000 --Apple-Mail=_7DDA0088-3CE8-4256-9E18-57462683480F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I=E2=80=99ve tried to merge the list of work items in the charter in a = single list and created a PR. Items have been merged and re-ordered in the following way: First the general standard track work item (multicast work merged here) Then other work with drafts more advanced appearing earlier. Milestone list will be updated once WG converged on this part. The list looks like: Main work items are identified as follows: Standard Track Documents: The core specifications of LISP have been = published as =E2=80=9CStandard Track=E2=80=9D ([RFC9300], [RFC9301]). = The WG will continue the work of moving select specifications to = =E2=80=9CStandard Track=E2=80=9D (e.g., [RFC8060], [RFC8111] and the set = of multicast documents like [RFC6831] and [RFC8378]). 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. Map Server Reliable Transport: LISP control plane messages are = transported over UDP, however, in some cases, the use of a reliable = transport protocol is a better fit, since it actually helps reduce = periodic signaling. LISP for traffic engineering: Specifics on how to do traffic engineering = on LISP deployments could be useful. For instance, encode in a mapping = not only the routing locators associated to EIDs, but also an ordered = set of re-encapsulating tunnel routers used to specify a path. LISP external connectivity: [RFC6832] defines the Proxy ETR element, to = be used to connect LISP sites with non-LISP sites. However, LISP = deployments could benefit from more advanced internetworking, for = instance by defining mechanism to discover such external connectivity. 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). 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. 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. [RFC7215], 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 [RFC7215]. Does it look as an acceptable trade-off among the various comments = received? Ciao L. > On Oct 11, 2023, at 14:33, Alberto Rodriguez-Natal (natal) = wrote: >=20 > Hi all, > =20 > A few thoughts on the charter after going through the latest revision = and the discussion on this thread. > =20 > * We have a milestone for LCAFbis, but LCAF is not mentioned in the = work items. Is LCAF supposed to be covered by the =E2=80=9CStandards = Track Documents=E2=80=9D work item? Same for DDT. If so, I would mention = them as examples of possible =E2=80=9CStandards Track Documents=E2=80=9D. = Also, I agree with Padma that we should extend the work item to include = =E2=80=9Clanguage to cover incremental features, behaviors and = specifications=E2=80=9D. > =20 > * I think the external connectivity work item could be generalized to = cover both the external-connectivity draft as well as any other work = adjacent to 6832, for instance something like: > =20 > =E2=80=9CLISP Internetworking: [RFC6832] defines the Proxy ETR = element, to be used to connect LISP sites with non-LISP sites. However, = LISP deployments could benefit from more advanced internetworking, for = instance by defining mechanism to discover such external = connectivity.=E2=80=9D > =20 > * Similar comment for TE. I think we could be more general, something = like: > =20 > =E2=80=9CTraffic Engineering and LISP: Specifics on how to do traffic = engineering on LISP deployments could be useful, for instance some use = cases=E2=80=A6=E2=80=9D > =20 > * On the milestones section, I think LCAFbis could be done much = sooner. Also, I agree with Dino we should have name-encoding sooner as = well (this is partly my fault, I=E2=80=99m halfway on my shepherds = writeup, will try to close on that). > =20 > * Based on the discussion on San Francisco, it is not entirely clear = to me the consensus of the WG regarding =E2=80=9CSubmitting a LISP = Applicability document to the IESG=E2=80=9D. Would it be possible to = leave this milestone somehow more open? > =20 > =20 > I=E2=80=99m also planning to send a PR on GitHub with some editorial = comments. > =20 > Thanks, > Alberto > =20 > From: Padma Pillay-Esnault > Date: Sunday, October 1, 2023 at 7:46=E2=80=AFPM > To: LISP mailing list list > Cc: lisp-chairs@ietf.org > Subject: Proposed WG Charter on GitHub >=20 > Hello all, > =20 > We have created a repository to gather input for the proposed LISP WG = charter presented in our last meeting. > =20 > A pointer to the repo below > https://github.com/lisp-wg/wg-charter > =20 > We welcome your comments and contributions. > =20 > Thanks > Padma and Luigi --Apple-Mail=_7DDA0088-3CE8-4256-9E18-57462683480F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I=E2=80=99ve tried to merge = the list of work items in the charter in a single list and created a = PR.


Items have been merged and re-ordered in = the following way:

First the general standard track work item (multicast = work merged here)

Then other work with drafts more advanced appearing = earlier.

Milestone = list will be updated once WG converged on this = part.


The list looks = like:

Main = work items are identified as follows:

  • Standard Track = Documents: The core specifications of LISP have been published as = =E2=80=9CStandard Track=E2=80=9D ([RFC9300], [RFC9301]). The WG will = continue the work of moving select specifications to =E2=80=9CStandard = Track=E2=80=9D (e.g., [RFC8060], [RFC8111] and the set of multicast = documents like [RFC6831] and [RFC8378]).

  • 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.

  • Map Server Reliable = Transport: LISP control plane messages are transported over UDP, = however, in some cases, the use of a reliable transport protocol is a = better fit, since it actually helps reduce periodic = signaling.

  • LISP for traffic engineering: Specifics on how to do traffic = engineering on LISP deployments could be useful. For instance, encode in = a mapping not only the routing locators associated to EIDs, but also an = ordered set of re-encapsulating tunnel routers used to specify a = path.

  • LISP external connectivity: [RFC6832] defines the Proxy ETR = element, to be used to connect LISP sites with non-LISP sites. However, = LISP deployments could benefit from more advanced internetworking, for = instance by defining mechanism to discover such external = connectivity.

  • 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).

  • 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.

  • 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. = [RFC7215], 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 [RFC7215].



Does it look as an = acceptable trade-off among the various comments = received?

Ciao

L.

On Oct 11, 2023, at 14:33, Alberto Rodriguez-Natal = (natal) <natal@cisco.com> wrote:

Hi = all,
 
A few thoughts on the charter after going = through the latest revision and the discussion on this = thread.
 
* We have a milestone for LCAFbis, but LCAF = is not mentioned in the work items. Is LCAF supposed to be covered by = the =E2=80=9CStandards Track Documents=E2=80=9D work item? Same for DDT. = If so, I would mention them as examples of possible =E2=80=9CStandards = Track Documents=E2=80=9D. Also, I agree with Padma that we should extend = the work item to include =E2=80=9Clanguage to cover incremental features, behaviors and = specifications=E2=80=9D.
 
* I think the external connectivity work item = could be generalized to cover both the external-connectivity draft as = well as any other work adjacent to 6832, for instance something = like:
 
=E2=80=9CLISP Internetworking: [RFC6832] = defines the Proxy ETR element, to be used to connect LISP sites with = non-LISP sites. However, LISP deployments could benefit from more = advanced internetworking, for instance by defining mechanism to discover = such external connectivity.=E2=80=9D
 
* Similar comment for TE. I think we could be = more general, something like:
 
=E2=80=9CTraffic = Engineering and LISP: Specifics on how to do traffic engineering on LISP = deployments could be useful, for instance some use = cases=E2=80=A6=E2=80=9D
 
* On the milestones = section, I think LCAFbis could be done much sooner. Also, I agree with = Dino we should have name-encoding sooner as well (this is partly my = fault, I=E2=80=99m halfway on my shepherds writeup, will try to close on = that).
 
* Based on the discussion on San Francisco, = it is not entirely clear to me the consensus of the WG regarding = =E2=80=9CSubmitting a LISP Applicability document to the IESG=E2=80=9D. = Would it be possible to leave this milestone somehow more = open?
 
 
I=E2=80=99m also planning = to send a PR on GitHub with some editorial = comments.
 
Thanks,
Alberto
 

From: Padma Pillay-Esnault = <padma.ietf@gmail.com>
Date: Sunday, October 1, 2023 = at 7:46=E2=80=AFPM
To: LISP mailing list list = <lisp@ietf.org>
Cc: lisp-chairs@ietf.org = <lisp-chairs@ietf.org>
Subject: Proposed WG Charter on = GitHub

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
 
We welcome your comments = and contributions.
 
Thanks
Padma and = Luigi
<= br>
= --Apple-Mail=_7DDA0088-3CE8-4256-9E18-57462683480F--