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

From: Warren Kumari <[email-masked]>
Date: Thu, 7 May 2020 14:21:19 -0400

<no-hats>

1) Support to adopt draft "draft-ymbk-lsvr-l3dl-*" as LSVR WG document?
Yes -- I support the adoption of BOTH draft-ymbk-lsvr-l3dl-signing and
draft-ymbk-lsvr-l3dl-ulpc.
I reviewed these documents (ulpc more thoroughly than signing) while
following the IDR BGP autoconfig work.

2) Are there any technical issues with this draft?
Only minor / editorial / opinions...
I *do* think that the last paragraph in Security Considerations of
ulpc should remain as is though,...

Nit:
"Any keying material in the PDU SHOULD BE salted ad hashed." - "and".

3) Which are current pain-points in the draft requiring additional
content and technical attention?
A: I suspect that there are missing attributes that should be added,
but I cannot think of any critical ones.
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?
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.

Apologies if these have already been discussed and I missed them...

4) What is missing from this draft?
See above...

W

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

---

From: Randy Bush <[email-masked]>
Date: Thu, 07 May 2020 12:16:40 -0700

thanks for the support

> ulpc should remain as is though,...

:)

> "Any keying material in the PDU SHOULD BE salted ad hashed." - "and".

thanks

> but I cannot think of any critical ones.

i admit to guilt-free obsessive minimalism

> building blocks that the IDR work might use, but where is the line

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.

> as a loopback? How do I know what route to install to reach the

l3dl 13.2 tells you it is a loopback

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.

needs 2119 language MUST HAVE BEEN :)

randy

---

From: Warren Kumari <[email-masked]>
Date: Thu, 7 May 2020 16:48:01 -0400

> i admit to guilt-free obsessive minimalism

Fair 'nuff.

> l3dl 13.2 tells you it is a loopback

Doh, I missed that...

>    The Encapsulation Flags are a sequence of bit fields as follows:

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

---

From: Randy Bush <[email-masked]>
Date: Thu, 07 May 2020 14:29:23 -0700

> 192.0.2.1, I need to know how to route *to* that address

you will likely want to forward, <pedantry> not route </pedantry>, to
the peer's address which was marked as Primary, iff it is in a subnet
which you also share.  if not, pick a forwarding next hop that is in a
subnet you share.  if there are multiple choices, you could have
signaled which subnet in an Upper Layer Protocol Configuration PDU
Attribute.

if you share no subnets, then you do not have a valid underlying l3dl
session see l3dl

   13.  The Encapsulations
   ....
   Further, to consider a logical link of a type to formally be
   established so that it may be pushed up to upper layer protocols, the
   addressing for the type must be compatible, e.g. on the same IP
   subnet.

yes, you have to hold a lot of gorp in your head.  sorry.

but some clarifying text might keep others from falling down this rabbit
hole.  thanks.

randy

---

From: Jacob Uecker <[email-masked]>
Date: Thu, 14 May 2020 19:30:05 -0700

I likewise fell down that line of thinking but your explanation makes sense.

1) I have read and support both draft-ymbk-lsvr-l3dl-signing and draft-ymbk-lsvr-l3dl-ulpc as LSVR WG documents.
2) Not that I saw
3) See above. 
4) I don’t have anything at this time.

> On May 7, 2020, at 2:29 PM, Randy Bush <[email-masked]> wrote:
> 
> _______________________________________________
> Lsvr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsvr