Re: [lisp] Rtgdir last call review of draft-ietf-lisp-vendor-lcaf-10

Dhruv Dhody <dd@dhruvdhody.com> Wed, 27 April 2022 03:48 UTC

Return-Path: <dd@dhruvdhody.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 4D0B1C07CFAF for <lisp@ietfa.amsl.com>; Tue, 26 Apr 2022 20:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.892
X-Spam-Level:
X-Spam-Status: No, score=-1.892 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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dhruvdhody-com.20210112.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 wcjrelv5S2rA for <lisp@ietfa.amsl.com>; Tue, 26 Apr 2022 20:48:51 -0700 (PDT)
Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 E15BBC20AF56 for <lisp@ietf.org>; Tue, 26 Apr 2022 20:48:40 -0700 (PDT)
Received: by mail-pj1-x1030.google.com with SMTP id w5-20020a17090aaf8500b001d74c754128so3953020pjq.0 for <lisp@ietf.org>; Tue, 26 Apr 2022 20:48:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w5fA4+6ZmfV+2obF0ycur07JaIY5gsdWlu4dBtPii5w=; b=RZRzh7NPN0swGFqtWDDnO4VGiUlbVtoFK8uz83ZTP5b8B4MsgvAwbn0Rg99iTFbhud CNNpHe1QIDQ70B0UNQobk82554KlzEqBFyChL1QWrhHH1/ZjKxVu+VDlN8buNHQazs6B uwosMJrhUSL3Lydov9x8zQq0wlslT4E67UZ+O54Bewv09gtYUevrKt8VTfkn3pESlH7C PufgfBbU6scbmxEMEaRMsR2mHxtS7dDTNSoYzEX+krewjHwMfPe3oWb9KAca8vHvoskw A0/nw2EJ6x18d78XGMbzM55bzqxEKFeQ1V3bPoXPQQbhnHQprhz7kP3c84O4jQHP4Ojz M4GQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w5fA4+6ZmfV+2obF0ycur07JaIY5gsdWlu4dBtPii5w=; b=QF77Zqi+ooB4DY/v+MODQhWq7qdv53U9S6UH2MMHVRy7uCeqpftJZ8wELNDbkbfnvd CXmN0gxFJ0sCmtUcTbCb656vuydwLF96p9m+rGpBYwp13oVEFHBYJCQJPtEAJLaZ7ej6 BDh2OJ/gEEK3WI7rVi11IBPjDsJeW6nx9u8Fk3flLinuj5VE0COv30AhuMJHgiYFuWW4 obVWNuVXNGVGiXjzJQTtFUo59e2Ksye34IIcqIxwElHtR93FY0k2fFTeiL3NolXKQUta 4qEHR3qkSV1vJPRE+3l1eY4ZUUmpZtseiMe4uiGpuJsxfDyUIkRQILAMFyDDdog8J8hW ZmuQ==
X-Gm-Message-State: AOAM532InUWnaX3MKqqycQyWmC0Our/thEaw2SV73omOm+gWnpSb9hbn BmvEMI9wrr9BDNQrINm7S/hdIaKererQmHkQXAusdQ==
X-Google-Smtp-Source: ABdhPJyJby3COhpK69U0jtA/nb00qKsLUoG1ySSHJHIRBM52FibUukEBnn3nP+2ROgvM6L16vD7BKk7uxfBzbnuzlMs=
X-Received: by 2002:a17:902:d717:b0:156:20a9:d388 with SMTP id w23-20020a170902d71700b0015620a9d388mr26849712ply.19.1651031320102; Tue, 26 Apr 2022 20:48:40 -0700 (PDT)
MIME-Version: 1.0
References: <165098180257.525.977533583517805963@ietfa.amsl.com> <BYAPR11MB3591085FFE95328E988F8334B6FB9@BYAPR11MB3591.namprd11.prod.outlook.com> <31ABB7B9-239C-4D19-8257-81211B76E868@gmail.com>
In-Reply-To: <31ABB7B9-239C-4D19-8257-81211B76E868@gmail.com>
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Wed, 27 Apr 2022 09:18:03 +0530
Message-ID: <CAP7zK5bL0ZOjw_93Q1OSe_nyVELUhs3PFZwBMcqbC6QMcVGuMg@mail.gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
Cc: "Alberto Rodriguez-Natal (natal)" <natal@cisco.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-lisp-vendor-lcaf.all@ietf.org" <draft-ietf-lisp-vendor-lcaf.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000059393205dd9aaf2f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/XvU2q9OY8M1YdxRxEX15aRxHj8I>
X-Mailman-Approved-At: Fri, 29 Apr 2022 08:03:32 -0700
Subject: Re: [lisp] Rtgdir last call review of draft-ietf-lisp-vendor-lcaf-10
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.34
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: Wed, 27 Apr 2022 03:48:55 -0000

Hi Dino,

In some protocols that I am aware of, it is usual to state that the
variable-length portion in the TLVs/objects is 4-byte aligned. But looking
at RFC 8060, I see that LISP does not follow this approach for any of the
LCAF and it works just fine without it. I agree with you that no change is
required then. Thanks for taking my comment into consideration.

Thanks!
Dhruv

On Wed, Apr 27, 2022 at 3:19 AM Dino Farinacci <farinacci@gmail.com> wrote:

> Dhruv, can you explain more specifically what you mean by padding? Since
> any LCAF encoding (even a vendor LCAF) has a length field, the encoding can
> be the exact number of bytes described by the length. So no padding is
> required.
>
> Or did you mean something else?
>
> Dino
>
> > On Apr 26, 2022, at 7:49 AM, Alberto Rodriguez-Natal (natal) <
> natal@cisco.com> wrote:
> >
> > Hi Dhruv,
> >
> > Thanks for your review! You’re bringing good points.
> >
> > As per your comment on padding, it’s a good question but I cannot recall
> right now any padding requirement in other LISP docs. A a quick search for
> ‘padding' in rfc6833bis and RFC8060 shows not results. Maybe someone else
> on the list can comment on padding requirements in LISP (if any)?
> >
> > Also, good point on expanding LISP on first use, we’ll make sure to do
> so in the revised draft.
> >
> > Thanks!
> > Alberto
> >
> > From: Dhruv Dhody via Datatracker <noreply@ietf.org>
> > Date: Tuesday, April 26, 2022 at 4:03 PM
> > To: rtg-dir@ietf.org <rtg-dir@ietf.org>
> > Cc: draft-ietf-lisp-vendor-lcaf.all@ietf.org <
> draft-ietf-lisp-vendor-lcaf.all@ietf.org>, last-call@ietf.org <
> last-call@ietf.org>, lisp@ietf.org<lisp@ietf.org>
> > Subject: Rtgdir last call review of draft-ietf-lisp-vendor-lcaf-10
> >
> > Reviewer: Dhruv Dhody
> > Review result: Has Issues
> >
> > I was assigned the reviewer today. I noticed that the IESG ballot is
> done and
> > the document is approved, I am not sure how valuable this review would
> be but
> > anyways...
> >
> > Hello,
> >
> > I have been selected as the Routing Directorate reviewer for this draft.
> The
> > Routing Directorate seeks to review all routing or routing-related
> drafts as
> > they pass through IETF last call and IESG review, and sometimes on
> special
> > request. The purpose of the review is to provide assistance to the
> Routing ADs.
> > For more information about the Routing Directorate, please see
> > ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> >
> > Although these comments are primarily for the use of the Routing ADs, it
> would
> > be helpful if you could consider them along with any other IETF Last Call
> > comments that you receive, and strive to resolve them through discussion
> or by
> > updating the draft.
> >
> > Document: draft-ietf-lisp-vendor-lcaf
> > Reviewer: Dhruv Dhody
> > Review Date: 2022-04-26
> > IETF LC End Date: Over
> > Intended Status: Experimental
> >
> > Summary:
> > I have some minor concerns about this document that I think should be
> resolved
> > before publication.
> >
> > Comments:
> > - The document is simple, clear and straightforward.
> >
> > Major Issues:
> > - No major issues found.
> >
> > Minor Issues:
> > - Is there any padding requirement that should be mentioned for the
> Internal
> > format in alignment with the rest of LISP? - Consider if adding an
> example in
> > the appendix would be useful for a casual reader.
> >
> > Nits:
> > - LISP does not have a * next to it at
> > https://www.rfc-editor.org/materials/abbrev.expansion.txt and thus
> should be
> > expanded on first use!
> >
> > Thanks!
> > Dhruv
> >
>
>