[lisp] Re: Routing Directorate Last Call Review for "LISP Distinguished Name Encoding" - draft-ietf-lisp-name-encoding-08
Acee Lindem <acee.ietf@gmail.com> Thu, 18 July 2024 16:07 UTC
Return-Path: <acee.ietf@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 EBE3EC15107A; Thu, 18 Jul 2024 09:07:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, 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 CMSTT92NAObI; Thu, 18 Jul 2024 09:07:56 -0700 (PDT)
Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d]) (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 66B22C14F6EE; Thu, 18 Jul 2024 09:07:56 -0700 (PDT)
Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-6561850a7bcso10596577b3.3; Thu, 18 Jul 2024 09:07:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721318875; x=1721923675; 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=5O7jvJTvZsvr1fKIo7V/UE4gpBsBpp9YtkT/B1Y1v6o=; b=jEfe6OZYiHrKWlNZqpVEazsk1R2TpG03buxeeaHX3naMC8b+zWoapffQT+oDHWwkZK 78DWATMh4Q6kwEteeCSCAHC4T70E+rogGZwBjQwfbFPPmSQ4D5shzCjIN1/FLrR0Cb50 JNas82osgXnsd2EbBkDCz+57WmC+FYnBO1sgaSWI+pNyLYOwDdn/wBwzm8XnJP5iQY9e vXkGsvgu1ez+aZWOtBJYkGQiPXIb1sj8jPzmk+20uEjyqH+3a/XjERDhGFUKV3rPnj3o 9oesuv23v+fzGX1rXGaI74lew1guzft8/w71K9tpe6Zl8toqIRlVCNT6xyf/Xrm4Tupk wZig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721318875; x=1721923675; 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=5O7jvJTvZsvr1fKIo7V/UE4gpBsBpp9YtkT/B1Y1v6o=; b=psqg3qjQdChuRtw/TD4ktneWRTCrz+RgLi83OXJf48x7s0xFW+FitiYA4w75eAnLJL 9fu3ODaExD0/j14oKJCBKJ77b0NzdHIdUkxXvWTMpfd8dRNnfkytW7ZS8IC2sUbTBx0R ff9EIduHq8qwQZ7/afFe45f1He8Vdt7d1d3IO9T71+bqDhfi8ZC3nJ5qFjoSGSqtVX7y fb4QzwZyWe3/p9qC7HDm2cr0BflImOnMGaIJoJF5aXcSssqKgiKQXg+JCJpng8MUFdiK h+Bts+HGpXYcMbtMTnKhr4cgoAqHOthMk2k4TY5hi3ZrYbEJ7LVc5CP4PkCJPa8VkCDg fKUw==
X-Forwarded-Encrypted: i=1; AJvYcCUyiMlAxs9wH3PjtYXKLMU8N0KA/JCyxGzyihpNkX4BPHMHqieYbikcSMUVaLHfqY469gYZe6ITPCLQMW7zKsOU0hPjoyTG5uuPlnzekWg+h4fo9PnpougSvlrXnjH0c6YsNI0yzxTj8Cj3OaIylVqL2DLeKRZhqtsyj+eiDNdqectCcEJNAIPyJfHc
X-Gm-Message-State: AOJu0YwiATRdYfIuvEvdEg9XXUjLfENyOqZfE6U+9EG4PqdDVPZ2MTIx U62jbrza7hfgHM9KrE//TRaQ7qn3YmJfG42DIlWJuR6XMdKjeI8Q
X-Google-Smtp-Source: AGHT+IEoJg/LAIVB99DHqPDM/YF9P4Bd9QcGUo48ETzqqb/an3VEL3foROLUsF9haf7VPDQ0etXemg==
X-Received: by 2002:a81:bf54:0:b0:645:2b26:5f64 with SMTP id 00721157ae682-664fb4412b5mr61594887b3.0.1721318875202; Thu, 18 Jul 2024 09:07:55 -0700 (PDT)
Received: from smtpclient.apple ([136.54.28.118]) by smtp.gmail.com with ESMTPSA id 00721157ae682-66603ed22a1sm3756587b3.120.2024.07.18.09.07.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jul 2024 09:07:54 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\))
From: Acee Lindem <acee.ietf@gmail.com>
In-Reply-To: <SJ0PR11MB5648A47F0E4E2CCB933EA372D2A32@SJ0PR11MB5648.namprd11.prod.outlook.com>
Date: Thu, 18 Jul 2024 12:07:44 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <74A1C5CB-F322-4439-A3AB-4231FBC00610@gmail.com>
References: <60F5074B-1ABF-4188-BAAB-93674065EF06@gmail.com> <E705921B-A423-4B79-81B3-4CF31F012B51@gmail.com> <79C9ECAD-293C-48B8-B125-3BDA967592F6@gmail.com> <0B98DA29-FE52-4697-9F50-B96C4F26C91E@gmail.com> <SJ0PR11MB5648A47F0E4E2CCB933EA372D2A32@SJ0PR11MB5648.namprd11.prod.outlook.com>
To: "Marc Portoles Comeras (mportole)" <mportole@cisco.com>
X-Mailer: Apple Mail (2.3731.700.6.1.1)
Message-ID-Hash: YHF7G4EOTXPGQTSGRBVWZ2ZU7N2U2VL6
X-Message-ID-Hash: YHF7G4EOTXPGQTSGRBVWZ2ZU7N2U2VL6
X-MailFrom: acee.ietf@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-lisp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "draft-ietf-lisp-name-encoding@ietf.org" <draft-ietf-lisp-name-encoding@ietf.org>, LISP mailing list list <lisp@ietf.org>, "rtgwg-ads@ietf.org" <rtgwg-ads@ietf.org>, Routing Directorate <rtg-dir@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [lisp] Re: Routing Directorate Last Call Review for "LISP Distinguished Name Encoding" - draft-ietf-lisp-name-encoding-08
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/UnceUPSpAaCllY561OuECsaZq68>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Owner: <mailto:lisp-owner@ietf.org>
List-Post: <mailto:lisp@ietf.org>
List-Subscribe: <mailto:lisp-join@ietf.org>
List-Unsubscribe: <mailto:lisp-leave@ietf.org>
HI Marc, > On Jul 18, 2024, at 11:51 AM, Marc Portoles Comeras (mportole) <mportole@cisco.com> wrote: > > Acee, > >>> 3. In section 9.2, The description of the onboarding process includes > >>> very specific details that aren't fully explained. Would it be > >>> possible to describe the use case at a higher level? > >> > >> This is some text from the cisco guys. I don't know how to change that. They have the intellectual property on it. > > >That’s fine with me then. It was just unclear to me how a DN would provide stability to the reliable transport session - would this allow the session to be recovered using a different UDP for? > The use-case described came up when running LISP in environments with endpoint mobility. > In those environments is not uncommon to have LISP xTRs that, at times, don’t have any endpoint locally connected. When this happens, these xTRs tear down the TCP connection (or don’t even start it) because they don’t have any EID to register with the Mapping System. > As you mention, when endpoints join the xTR again, the whole cycle starts again. New EIDs are available, first a new UDP registration is sent and then the xTR and MS re-establish the TCP session. > To avoid this churn the DN registration comes very handy, because it creates a permanent EID to register and avoids constantly bringing the TCP session up and down. Even with my very high-level understanding of LISP, this makes sense to me. I'll leave it to you as to whether you add a clarifying statement regarding the permanent EID. Thanks, Acee > Thanks, > Marc > From: Dino Farinacci <farinacci@gmail.com> > Date: Tuesday, July 16, 2024 at 1:18 PM > To: Acee Lindem <acee.ietf@gmail.com> > Cc: draft-ietf-lisp-name-encoding@ietf.org <draft-ietf-lisp-name-encoding@ietf.org>, LISP mailing list list <lisp@ietf.org>, rtgwg-ads@ietf.org <rtgwg-ads@ietf.org>, Routing Directorate <rtg-dir@ietf.org>, Marc Portoles Comeras (mportole) <mportole@cisco.com>, Dino Farinacci <farinacci@gmail.com> > Subject: Re: Routing Directorate Last Call Review for "LISP Distinguished Name Encoding" - draft-ietf-lisp-name-encoding-08 > > This exposes my only high-level knowledge of the protocol itself. Maybe add a reference to [RFC9301] here as well. > > I will add. > > >> > >>> 2. In section 5, the final sentence fragment didn't parse and it > >>> wasn't obvious to me how to edit it - "As well as identifying > >>> the router name...". > >> > >> Fixed. Thanks. > >> > >>> 3. In section 9.2, The description of the onboarding process includes > >>> very specific details that aren't fully explained. Would it be > >>> possible to describe the use case at a higher level? > >> > >> This is some text from the cisco guys. I don't know how to change that. They have the intellectual property on it. > > > > That’s fine with me then. It was just unclear to me how a DN would provide stability to the reliable transport session - would this allow the session to be recovered using a different UDP for? > > I don't know. I have copied Marc Portoles explicitly so he can comment. > > Thanks, > Dino
- [lisp] Routing Directorate Last Call Review for "… Acee Lindem
- [lisp] Re: Routing Directorate Last Call Review f… Dino Farinacci
- [lisp] Re: Routing Directorate Last Call Review f… Dino Farinacci
- [lisp] Re: Routing Directorate Last Call Review f… Acee Lindem
- [lisp] Re: Routing Directorate Last Call Review f… Marc Portoles Comeras (mportole)
- [lisp] Re: Routing Directorate Last Call Review f… Acee Lindem
- [lisp] Re: Routing Directorate Last Call Review f… Marc Portoles Comeras (mportole)