Subject: [Lsvr] WGLC for draft-ietf-lsvr-l3dl-ulpc-01 (to end February 19, 2021)

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 4 Feb 2021 04:09:13 +0000

Hi All,

This work contains the L3DL Upper Layer Protocol Configuration extensions to communicate the parameters needed to exchange inter-device Upper Layer Protocol Configuration for upper layer protocols such as the BGP family.

The LSVR WG initiates a working group last call for draft-ietf-lsvr-l3dl-ulpc-01". Please send your comments to the list before Friday February 19, 2021. 

https://tools.ietf.org/html/draft-ietf-lsvr-l3dl-ulpc-01.html

All, please reply on-list indicating if you're aware of an implementation.
If not already completed, please reply on-list indicating if you're aware of any relevant IPR.

Brgds,
Gunter & Victor
LSVR WG co-chairs

---

From: Warren Kumari <[email-masked]>
Date: Fri, 5 Feb 2021 16:45:25 -0500

On Wed, Feb 3, 2021 at 11:09 PM Van De Velde, Gunter (Nokia -
> https://tools.ietf.org/html/draft-ietf-lsvr-l3dl-ulpc-01.html

<no hats>
I support this document being published.

I'm part of the IDR Autoconf design team, and, in my personal opinion,
L3DL/L3DL-ULPC is the most promising solution for our requirements. As
we get more deployment experience / fully explore the problem space we
may need a -bis / extensions / similar, but I think that it is well
worth publishing this now, so we get more deployment and
implementations.

I personally believe that it makes sense to have a registry for the
Attribute List ("a, possibly null, set of sub-TLVs describing the
configuration attributes of the specific upper layer protocol."), and
that this might need to be a larger code space than a single octet;
there are a number of use case/deployment scenarios.
Some set of people will want to configure their own "meanings" for
attributes before deploying devices, but some set of people would like
to rely on some well known (e.g: "I'm at Stage2 in a Clos fabric",
"I'm a fabric egress node", "I'm an edge type node") attributes so
that they can do less manual bootstrapping.

I also think that a larger (16 bit) code space would be better (partly
because of the above) - as a bikeshedding opportunity, a registry with
1-1024 as RFC Required, 1025-2048 as Spec, 2048-4096 as FCFS, and
4096-65535 as Private Use / whatever seems good to me.
If we stick with 8 bit, I still think it is worth making the first 32
codepoints be well-know/registered and people define the meaning for
the rest to mean whatever they want on their network.

Whatever the case, I support this - it is an important and useful document.

I do have a few questions, and some nits.
Q1: "Otherwise a direct one hop session is
   used.  the BGP session to a loopback will forward to the peer's
   address which was marked as Primary in the L3DL Encapsulation Flags,
   iff it is in a subnet which is shared with both BGP speakers."
I'm unclear if the 'iff' is just a typo, or if it short for "if and
only if". Also a nit on 'the BGP session' - this is fragment or needs
an upper case 'T'

1: I think that s/upper layer/upper-layer/g
2: s/IP layer 3/IP Layer-3/g
3: "ULPC Type: An integer denoting the type of the uper layer
protocol" - uper is a typo.
4: "it might be a simple MD5 key (see [RFC2385]), the name of a key
chain a KARP database" - "chain *in* a KARP"

W

> _______________________________________________
> Lsvr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsvr

--
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: Randy Bush <[email-masked]>
Date: Sat, 06 Feb 2021 12:37:04 -0800

> <no hats>

in the weather you're having?

> L3DL/L3DL-ULPC is the most promising solution for our requirements.

personally, i would hack it a bit differently for that target.  but
that's in another galaxy far away.

> As we get more deployment experience / fully explore the problem space
> we may need a -bis / extensions / similar

no extra charge

> that this might need to be a larger code space than a single octet;

<pedantry>
i presume you mean for attributes, not for the list.

given wg support, i do not have a big objection to s/octet/16 bits/

> there are a number of use case/deployment scenarios.  Some set of
> people will want to configure their own "meanings" for attributes
> before deploying devices, but some set of people would like to rely on
> some well known (e.g: "I'm at Stage2 in a Clos fabric", "I'm a fabric
> egress node", "I'm an edge type node") attributes so that they can do
> less manual bootstrapping.

as long as i do not have to be in, or at least not listen to, the wg
that decides and forever extends the well-known attribute list.

> 4096-65535 as Private Use / whatever seems good to me.  If we stick
> with 8 bit, I still think it is worth making the first 32 codepoints
> be well-know/registered and people define the meaning for the rest to
> mean whatever they want on their network.

that is a bit complex for my taste; but it does solve some traditional
messes.  presuming we're good at guessing the boundaries.

and "1025-2048 as Spec" scares me.  i hope you are not suggesting we go
down the rabbit hole of selecting a set of well-known values in *this*
draft.  i can hear it now, "my clos uses whitworth bolts."

> Whatever the case, I support this - it is an important and useful

thanks

> Q1: "Otherwise a direct one hop session is used.  the BGP session to a
>    loopback will forward to the peer's address which was marked as
>    Primary in the L3DL Encapsulation Flags, iff it is in a subnet
>    which is shared with both BGP speakers."
> only if".

you want well-known attributes; i want to use well-known notation :)

> Also a nit on 'the BGP session' - this is fragment or needs an upper
> case 'T'

thx

> 2: s/IP layer 3/IP Layer-3/g

that could be either way.  normally, i would let the rfc editor hack.
no matter what i choose, rfced seems to go the other way.

> protocol" - uper is a typo.

whoops

> chain a KARP database" - "chain *in* a KARP"

ibid

thanks!

randy

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 12 Feb 2021 04:07:10 +0000

[+IDR WG]

Hi all,

Please find this reminder for WGLC. The WGLC can use additional review comments.
Please use lsvr email list for providing feedback and comments.

Be well,
G/

-----Original Message-----
From: Van De Velde, Gunter (Nokia - BE/Antwerp) 
Sent: Thursday, February 4, 2021 11:09
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: WGLC for draft-ietf-lsvr-l3dl-ulpc-01 (to end February 19, 2021)

Hi All,

Brgds,
Gunter & Victor
LSVR WG co-chairs