From padma.ietf@gmail.com Fri Oct 13 10:49:56 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 C10EAC15107A; Fri, 13 Oct 2023 10:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.107 X-Spam-Level: X-Spam-Status: No, score=-7.107 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, 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=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HQe8wpxfv5j; Fri, 13 Oct 2023 10:49:54 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 6669CC15106A; Fri, 13 Oct 2023 10:49:54 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-2bff776fe0bso30079491fa.0; Fri, 13 Oct 2023 10:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697219392; x=1697824192; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SF96PZFrvv4e4U1bc75avmFsVHQzg/PHCvWHZl5EiCc=; b=d5GD28kE1YQJ2iqtvWZbX5UO2WDjlkCv89wVMAvVBKSuxR5Px9GumCs593ij69McKx MzlcrrU36fl//JMvoiWnvVeZFGmi12A/f4OIvIPBs1z05RMoWDxQjG1V+a3oks4uiQqr ju5kW4MRfW3NA3Ipl8VTNtCmqfClnjAg+gnDxE3KLSSJXA+wYTlOGJUvQkdsmd9n7D+p SRvxJQTovj4MdEJj0L31ePlVuJgL+1bHGFdkh3nwHfSxVjMEWtyV9+QJmuu0ZbYhaeBH 3kvqrNpGAXaZXWAoL7XAs1ZVnL7ZTA2dDbCF9l/2PB9h8Ms5tJBR45pwtJARYxv0UuIW xk5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697219392; x=1697824192; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SF96PZFrvv4e4U1bc75avmFsVHQzg/PHCvWHZl5EiCc=; b=k7oWbbcZ3TMz4XWL99QG2+TFhWSrtcwqq64SeE31Ce+rpY4aK4/wK3lhxlHaLYJePp N51p1AIXZnmixAklhw0J+i45HbEcce4HX0vsvPi5OZ/fl0/xRl3BR0rV3xJlKzHq3STc vy5zDfUjQ9mx2espOsRExbVA/AGCGAiRJOCZkRpmSLP0ohlAj08zMOhSjHQBWArYfAhs L9EDToOeh9w8E2Gyh2pdYZ2ioXWheMbyrV7a5a3nK/iaeODGPzdfbCmCj6BQADgL9xw3 2kl6Urr4O9eWt/vTEgK265YSWvODoqzIWkPIskXZumP+uNMp5qfG/CtY59hlmQQGNMBm imCw== X-Gm-Message-State: AOJu0YxHBz2L07QQah9JJZ4OSPdBSWze0ZAzmjPdmOfyKEVGvdV8vWZG dklrLCfsf0+hQf8XMlXHk0Vvxg85cCYFQg7Sxpw= X-Google-Smtp-Source: AGHT+IFtl3C7jm2iyCrwNTwn4HsUqfr+SJx2Y+uThmChqQw+YxMsXQJU11cfx5IsIpZGYXE8JX2CZhIovEVUezGVehk= X-Received: by 2002:a2e:8816:0:b0:2bc:db99:1775 with SMTP id x22-20020a2e8816000000b002bcdb991775mr22858939ljh.26.1697219391427; Fri, 13 Oct 2023 10:49:51 -0700 (PDT) MIME-Version: 1.0 References: <7AA2F620-1223-4C17-A3D8-3F9D2AFEDBF5@gigix.net> In-Reply-To: From: Padma Pillay-Esnault Date: Fri, 13 Oct 2023 10:49:40 -0700 Message-ID: To: Luigi Iannone Cc: LISP mailing list list , "lisp-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ee966606079cae1a" Archived-At: Subject: Re: [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 17:49:56 -0000 --000000000000ee966606079cae1a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Additional comments/suggestions Milestones To be consistent, we should have at least a milestone for each of the larger sections. There is a couple missing: - TE section - suggest March 2025 - Privacy and Security section - suggest Nov 2025 or March 2026 Format To be consistent with other sections, we should have "Yang Model:" format. Ordering I would not propose to order as sections matching the milestones as sections may have different documents at different maturity levels. However this one caught my attention: should we move up "NAT transversal" section to after "Yang Model:" as it is in March 2024. Thanks Padma On Fri, Oct 13, 2023 at 10:21=E2=80=AFAM Padma Pillay-Esnault wrote: > Hi Luigi > > Looks good to me > nit/suggestion below see PPE > > Padma > > On Fri, Oct 13, 2023 at 2:05=E2=80=AFAM Luigi Iannone wro= te: > >> Hi, >> >> I=E2=80=99ve tried to merge the list of work items in the charter in a s= ingle >> 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]). >> >> PPE - Reading this the "standard track document" bullet kinda implies > that the docs below are not standard track. > Suggestion - "Moving to Standard tracks:" > > > >> >> - >> >> YANG models for managing the LISP protocol and deployments that >> include data models, OAM, as well as allowing for programmable manage= ment >> interfaces. These management methods should be considered for both th= e >> 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 pe= riodic >> 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 ins= tance >> 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 rou= ters >> 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 connectivit= y. >> - >> >> Privacy and Security: The WG will work on topics of EID anonymity, >> VPN segmentation leveraging on the Instance ID, and traffic anonymiza= tion. >> 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 du= ring >> its design phase. [RFC7215], while remaining a good source of informa= tion, >> covers one single use case, which is not anymore the main LISP applic= ation >> 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 an= d >> 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 Do= cuments=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 increm= ental >> 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 deployment= s >> could benefit from more advanced internetworking, for instance by defini= ng >> 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 en= gineering >> 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 (thi= s >> is partly my fault, I=E2=80=99m halfway on my shepherds writeup, will tr= y 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 Applicab= ility >> document to the IESG=E2=80=9D. Would it be possible to leave this milest= one somehow >> more open? >> >> >> I=E2=80=99m also planning to send a PR on GitHub with some editorial com= ments. >> >> Thanks, >> Alberto >> >> >> *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 >> 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 >> >> >> --000000000000ee966606079cae1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Additional comments/suggestions

Milestones=C2=A0
To be cons= istent, we should have at least a milestone for each of the larger sections= . There is a couple missing:
- TE section - suggest March 2025
- Privacy and Security section - suggest Nov 2025 or March 2026
=

Format
To be consistent with other sections, = we should have "Yang Model:" format.

Ordering=C2=A0
I would not propose to order as sections ma= tching the milestones as sections may have different documents at different= maturity=C2=A0levels.=C2=A0 However this one caught my attention: should w= e move up "NAT transversal" section =C2=A0to after "Yang Mod= el:" as it is in March 2024.

Thanks
=
Padma


On Fri, Oct 13, 2023 at 10:21=E2=80=AFAM Pad= ma Pillay-Esnault <padma.ietf@gm= ail.com> wrote:
Hi Luigi=C2=A0

Looks good to me=C2=A0
nit/suggestion below see PPE=C2=A0

Padma

On = Fri, Oct 13, 2023 at 2:05=E2=80=AFAM Luigi Iannone <ggx@gigix.net> wrote:
Hi,

I=E2=80=99ve tried to merge the list of work items in the charter in a s= ingle 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 follow= s:

  • Standard Track Documents: The core specifications of LISP hav= e 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 multi= cast documents like [RFC6831] and [RFC8378]).

PPE - Reading this the "standard track document" bu= llet kinda implies that the docs below are not standard=C2=A0track.=C2=A0
Suggestion - "Moving to Standard tracks:"

=
=C2=A0

  • YANG models for managing the LISP protocol and deploy= ments that include data models, OAM, as well as allowing for programmable m= anagement interfaces. These management methods should be considered for bot= h the data-plane, control plane, and mapping system components.=C2=A0

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

  • LISP for traffic engineering: S= pecifics on how to do traffic engineering on LISP deployments could be usef= ul. For instance, encode in a mapping not only the routing locators associa= ted to EIDs, but also an ordered set of re-encapsulating tunnel routers use= d to specify a path.

  • LISP external connectivity: [RFC6832] defin= es the Proxy ETR element, to be used to connect LISP sites with non-LISP si= tes. However, LISP deployments could benefit from more advanced internetwor= king, for instance by defining mechanism to discover such external connecti= vity.

  • NAT-Traversal: Support for NAT-traversal solution in deplo= yments where LISP tunnel routers are separated from correspondent tunnel ro= uters by a NAT (e.g., LISP mobile node).

  • Mobility: Some LISP dep= loyment scenarios include mobile nodes (in mobile environments) or Virtual = Machines (VMs in data centers), hence, support needs to be provided in orde= r to achieve seamless connectivity.

  • Privacy and Security: The WG= will work on topics of EID anonymity, VPN segmentation leveraging on the I= nstance ID, and traffic anonymization. The reuse of existing mechanisms wil= l be prioritized.

  • LISP Applicability: In time, LISP has proved t= o be a very flexible protocol that can be used in various use-cases not eve= n considered during its design phase. [RFC7215], while remaining a good sou= rce of information, covers one single use case, which is not anymore the ma= in LISP application scenario. The LISP WG will document LISP deployments fo= r 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:

H= i all,
=C2=A0<= u>
A few thoughts on the charte= r after going through the latest revision and the discussion on this thread= .
=C2=A0
* We have a milestone for LCAFbis= , but LCAF is not mentioned in the work items. Is LCAF supposed to be cover= ed by the =E2=80=9CStandards Track Documents=E2=80=9D work item? Same for D= DT. 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 th= e work item to include =E2=80=9Clangu= age to cover incremental features, behaviors and specifications=E2=80=9D.
=C2=A0
* I think the external connectivity work item could be generalized to= cover both the external-connectivity draft as well as any other work adjac= ent to 6832, for instance something like:
=C2=A0
=E2=80=9CLISP Internetworking: [RFC6832] defines the Proxy ETR eleme= nt, to be used to connect LISP sites with non-LISP sites. However, LISP dep= loyments could benefit from more advanced internetworking, for instance by = defining mechanism to discover such external connectivity.=E2=80=9D<= u>
=C2=A0<= /div>
* Similar comment for TE. I think we could= be more general, something like:
=C2=A0
= =E2=80=9CTraffic Engineering and LISP: Specifics on how to do traffic engin= eering on LISP deployments could be useful, for instance some use cases=E2= =80=A6=E2=80=9D
=C2=A0
* On the milestones= section, I think LCAFbis could be done much sooner. Also, I agree with Din= o 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).<= /u>
=C2=A0
* Based on the discussion on San Franc= isco, 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?
=C2=A0
=C2=A0
I=E2=80=99m also planning to send a PR on GitHub with some editori= al comments.
= =C2=A0
Thanks,=
Alberto
=
=C2=A0

From:=C2=A0Padma Pi= llay-Esnault <= padma.ietf@gmail.com>
Date:=C2=A0Sunday, Octo= ber 1, 2023 at 7:46=E2=80=AFPM
To:=C2=A0LISP mailing= list list <lisp@ietf= .org>
Cc:=C2=A0lisp-chairs@ietf.org <lisp-chairs@ietf.org>
= Subject:=C2=A0Proposed WG Charter on GitHub<= /span>

Hello all,
= =C2=A0
We have created a repository to gather input for the proposed LISP = WG charter presented in our last meeting.
<= div>
=C2=A0
A pointer to the r= epo below
=C2= =A0
We welcome your comments and contributions.
=C2=A0
Thanks
Padm= a and Luigi

--000000000000ee966606079cae1a--