Re: [Lsvr] Adoption of draft-ymbk-lsvr-l3dl-(signing|ulpc)

Warren Kumari <warren@kumari.net> Thu, 07 May 2020 20:48 UTC

Return-Path: <warren@kumari.net>
X-Original-To: lsvr@ietfa.amsl.com
Delivered-To: lsvr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CE53A0DA7 for <lsvr@ietfa.amsl.com>; Thu, 7 May 2020 13:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBAdzuBZdspR for <lsvr@ietfa.amsl.com>; Thu, 7 May 2020 13:48:41 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D84033A0DA5 for <lsvr@ietf.org>; Thu, 7 May 2020 13:48:40 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id a21so7805679ljb.9 for <lsvr@ietf.org>; Thu, 07 May 2020 13:48:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PeLYmIkyxt2+KvE17Thk/2aV1RU0EEP4rJGzu4yCmsY=; b=d33aqErSSgPT2A6K7d5o0L98eeUNriimcKEBXw2R+FE9Ryz3MnjePbctCkwFqH9e9F fSax4SN6X89O8JxG4PMh0Nfu03M5tbwSc2Q67OpEJchMnJtcGnNy6vrs+z0Z/n4duouM XnzZTFND86OqANudR+iDUs///p5NRz2Yf/GP1JQHSh6GlNpM5jGe4Fh9qj1wm6aMixAz kGvU380xwSvIfKBgrn0l4HGESr+hv+bK+cx/XV6543DYTEL1a57e+MI+iJUkSn+l0eGc SWr+8LcNhWw2dYU6RvwqocF+DFu2zOn4YxHzPe3DjCz7riSLDxqeREkoqZNc/FTDEyJ4 MVhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PeLYmIkyxt2+KvE17Thk/2aV1RU0EEP4rJGzu4yCmsY=; b=p3SI0f/REeDiABtZU18ygc9gZ0fCjGuNzJHH7LPF2hNpG4K8/ROhq+ZsS+kOuKnc1Y 2fbkGB0rXxavhXH9O7URyP5mNdCX0sY/Bafxnho7G/Fv4SzTzMWYUwhPrFsXW7HmODFe EoHoFLQOQ21A3y2aX51A2v3XhpR0HLjJQZk6zzR2SW0isRPGqr/lTSkoTil+/Dq8wcrV dC0nSsTSJWhZjepWRGI0b4mQpiyC+x8SS/O5a7nVTwtwpupRU1dAC0seRrTUwo8Q8Z8b tLhKFIwhBio1Lz3LSLUzmgx39na7ALUf5kfqEE+1JfUh+8vTjknINdzpglvFNtKh9D3S Of7Q==
X-Gm-Message-State: AGi0PubxIYNM6VQMVJjwMVcLK94y+jpITSwO6bCQlV8KOptgJQvbhBkv NDvxi2wVZIS89MWSmar/DW1D9/5sqB062BMz/aLr/Q==
X-Google-Smtp-Source: APiQypJrO299gfQmiuwGiBMrO3T7ElIuIGRSlXUcq6ngf4BG53cXgSFMXF1tKtyp0kmmvp6Z/BxN58Ac3iKfIGYFieg=
X-Received: by 2002:a2e:9048:: with SMTP id n8mr9752834ljg.122.1588884518210; Thu, 07 May 2020 13:48:38 -0700 (PDT)
MIME-Version: 1.0
References: <CAHw9_i+p8Dvo37Cm_=Ehj=G+YPmVHUaU7wNzOLCddxV-BRFEBQ@mail.gmail.com> <m2o8qzk12f.wl-randy@psg.com>
In-Reply-To: <m2o8qzk12f.wl-randy@psg.com>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 7 May 2020 16:48:01 -0400
Message-ID: <CAHw9_iKCPhkDTGXt6_n1JcReU1KBp1kqEVTuTXJuz6+rGFVJ6g@mail.gmail.com>
To: Randy Bush <randy@psg.com>
Cc: lsvr@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/bEsQd3G4yJZrC8FaPrYCouxx5w4>
Subject: Re: [Lsvr] Adoption of draft-ymbk-lsvr-l3dl-(signing|ulpc)
X-BeenThere: lsvr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Vector Routing <lsvr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsvr>, <mailto:lsvr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsvr/>
List-Post: <mailto:lsvr@ietf.org>
List-Help: <mailto:lsvr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsvr>, <mailto:lsvr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 May 2020 20:48:46 -0000

On Thu, May 7, 2020 at 3:16 PM Randy Bush <randy@psg.com> wrote:
>
> thanks for the support
>
> > I *do* think that the last paragraph in Security Considerations of
> > ulpc should remain as is though,...
>
> :)
>
> > "Any keying material in the PDU SHOULD BE salted ad hashed." - "and".
>
> thanks
>
> > A: I suspect that there are missing attributes that should be added,
> > but I cannot think of any critical ones.
>
> i admit to guilt-free obsessive minimalism

Fair 'nuff.

>
> > B: I'm not 100% sure what the relationship is between this and the IDR
> > BGP AutoConf work is - this looks like it provides much of the
> > building blocks that the IDR work might use, but where is the line
> > between them?
>
> ships in the night
>
> but i agree that this is useful as an example in the idr-dt.  fwiw, i
> have queued homework over there.
>
> > C: It feels like more text is needed around "If a peering address has
> > been announced as a loopback, a two or three (one or both ends could
> > be loopbacks) hop
> >    BGP session will be established. " -- how do I know it is announced
> > as a loopback? How do I know what route to install to reach the
> > loopback? etc.
>
> l3dl 13.2 tells you it is a loopback

Doh, I missed that...

>
> 13.2.  Encapsulaion Flags
>
>    The Encapsulation Flags are a sequence of bit fields as follows:
>
>     0           1            2            3            4  ...       7
>    +------------+------------+------------+------------+------------+
>    |  Ann/With  |   Primary  | Under/Over |  Loopback  | Reserved ..|
>    +------------+------------+------------+------------+------------+
>
> so how about
>
>    For each BGP peering on a link here MUST be one agreed encapsulation,
>    and the addresses used MUST be in the corresponding L3DP IPv4/IPv6
>    Announcement PDUs.  If a peering address has been announced as a
>    loopback, i.e. MUST BE flagged as such in the L3DL Encapsulation PDU,
>    a two or three hop BGP session will be established.  Otherwise a
>    direct one hop session is used.

Close but no cigar -- I suspect I didn't fully explain my (second) question
If router A says that I should peer with the loopback address
192.0.2.1, I need to know how to route *to* that address (this is
sometimes confusingly called a recursive route, a term which has
always seemed silly to me) -- is this route something that l3dl-ulpc
should talk about, or is that something that a different document
covers, or am I just off in the weeds?


Whatever the case, I support adoption.

>
> needs 2119 language MUST HAVE BEEN :)

You are welcome to write a -bis :-)
W

>
> randy



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf