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

On Wed, Feb 3, 2021 at 11:09 PM Van De Velde, Gunter (Nokia -
BE/Antwerp) <gunter.van_de_velde@nokia.com> wrote:
>
> 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

<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

>
> 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
>
> _______________________________________________
> Lsvr mailing list
> Lsvr@ietf.org
> 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