Subject: [lisp] Unknown LCAF Types (?) (draft-ietf-lisp-vendor-lcaf)

From: Alvaro Retana <[email-masked]>
Date: Wed, 13 Apr 2022 04:39:30 -0700

Hi!

The recent GenArt review and the comment about unknown OUIs got me
thinking.  What should a LISP device do if it receives an unknown LCAF
Type?

It seems to me that the intent is to tightly control the use of
specific LCAFs in specific deployments.  Nonetheless, there's always a
chance than an unknown Type is received.  I looked at rfc8060 but
found no indication there.  Did I miss it?

I assume that the message containing an unknown Type MUST be dropped.
Or should it just be the specific TLV?

In either case, if that is not specified then we could use
draft-ietf-lisp-vendor-lcaf to specify that behavior -- and formally
update rfc8060.

??

Thanks!

Alvaro.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 13 Apr 2022 10:50:31 -0700

> Or should it just be the specific TLV?

It should be ignored. The term "dropped" implies the packet with an unknown LCAF should be dropped. But there can be other LCAFs encoded that are knownn that should be processed.

Here is an example:

An EID-record with an rloc-count of 3, one RLOC-record is an IPv4 address, another one an IPv6 address, and the final one is a "foobar" address (or unknown). The EID should be processed with an RLOC-set of 2.

Dino

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 13 Apr 2022 11:39:13 -0700

Hi!

That makes sense.

Just confirm, the behavior is not specified in rfc8060, right?  It seems to
me that it would be good to specify it somewhere
and draft-ietf-lisp-vendor-lcaf looks as good a place as any - do you agree?

Thanks!

Alvaro.

> Or should it just be the specific TLV?

It should be ignored. The term "dropped" implies the packet with an unknown
LCAF should be dropped. But there can be other LCAFs encoded that are
knownn that should be processed.

Here is an example:

An EID-record with an rloc-count of 3, one RLOC-record is an IPv4 address,
another one an IPv6 address, and the final one is a "foobar" address (or
unknown). The EID should be processed with an RLOC-set of 2.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 13 Apr 2022 12:02:23 -0700

> Just confirm, the behavior is not specified in rfc8060, right?  It seems to me that it would be good to specify it somewhere and draft-ietf-lisp-vendor-lcaf looks as good a place as any - do you agree?

I search as well and it wasn't obviously stated. But 6833bis has this text:

Which doesn't make clear if the LCAF AFI is supported but the LCAF type is NOT supported, the LCAF type should be dropped.

Should we add this to rfc6833bis?

The suggested text would be:

. . . LISP control-plane messages that include an unrecognized AFI or LCAF-Type MUST be dropped . . .

Dino

---

From: "Prakash Jain (prakjain)" <[email-masked]>
Date: Wed, 13 Apr 2022 21:33:15 +0000

Since its vendor specific LCAF, vendor might intend to use this for its vendor spefic usage/purpose in generic lisp message. Means, if recever is same vendor as transmitter, that usage is applicable, otherwise ignore/drop vendor specific LCAF but generic lisp message should still be procssed as per lisp specification.

Hence, for unknown LCAF, only tlv should be droped and not whole message.

My 2 cents..
Thanks,
Prakash

________________________________
From: lisp <[email-masked]> on behalf of Alvaro Retana <[email-masked]>
Sent: Wednesday, April 13, 2022, 4:39 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [lisp] Unknown LCAF Types (?) (draft-ietf-lisp-vendor-lcaf)

Hi!

??

Thanks!

Alvaro.

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

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 13 Apr 2022 14:39:03 -0700

> On Apr 13, 2022, at 2:33 PM, Prakash Jain (prakjain) <[email-masked]> wrote:
> 

Agree.

But even with same vendor but old implementation, the LCAF type should be ignored by old when new sends to old. 

Dino

---

From: "Prakash Jain (prakjain)" <[email-masked]>
Date: Wed, 13 Apr 2022 22:16:18 +0000

> But even with same vendor but old implementation, the LCAF type should be ignored by old when new sends to old.

Yes, agree.
Thanks,
Prakash

    Agree.

    Dino

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 14 Apr 2022 04:39:40 -0700

Hi!

Hmm — let’s start with the positive.  The new text looks good to me.

OTOH, even if rfc6833bis is the base specification, rfc8060 is an optional
extension…. The problem is one of references and document status:

rfc8060 is an Experimental document — the current reference in rfc6833bis
is Informative, which is ok because there’s just a general reference to the
AFI — “LCAF-Type MUST” makes the relationship to rfc8060 Normative and
changes the behavior of rfc8060 implementations, so we should change the
reference type and formally update rfc8060, which results in a downref,
which requires community approval (new IETF LC), which requires the IESG to
consider the downref registry, . . .

I don’t think any of us wants to reopen rfc6833bis at this point. <sigh>

Ideally, rfc8060 would have included that one extra sentence: “an
unrecognized LCAF-Type MUST be dropped”.

We have two other options:

(1) Let it be.  rfc8060 is Experimental, people “experimenting” with it can
figure it out, and when/if the document goes on the Standards Track we can
add the text.  I know there are production deployments, but these are
mostly controlled (people shouldn’t see unknown types).

(2) Use lisp-vendor-lcaf, which adds a new Type, to formally update rfc8060
on what needs to be done if an unknown Type is received.  Both documents
are Experimental and lisp-vendor-lcaf is in line to be approved next week
by the IESG, so there are no cumbersome process issues.

So…what does the WG want to do?  reopen rfc6833bis, nothing, or use
lisp-vendor-lcaf

[FWIW, my personal preference (as WG participant) is to use
lisp-vendor-lcaf.]

Thanks!

Alvaro.

On April 13, 2022 at 3:02:28 PM, Dino Farinacci ([email-masked]) wrote:

Just confirm, the behavior is not specified in rfc8060, right?  It seems to
me that it would be good to specify it somewhere and
draft-ietf-lisp-vendor-lcaf looks as good a place as any - do you agree?

Which doesn't make clear if the LCAF AFI is supported but the LCAF type is
NOT supported, the LCAF type should be dropped.

. . . LISP control-plane messages that include an unrecognized AFI or
LCAF-Type MUST be dropped . . .

Dino

---

From: "Alberto Rodriguez-Natal (natal)" <[email-masked]>
Date: Thu, 14 Apr 2022 13:56:08 +0000

Hi Alvaro, all,

I think it is fine to include the new line in lisp-vendor-lcaf, but I would phrase it as follows: “an unrecognized LCAF-Type MUST be skipped”, so it is clear that not the full packet is dropped but just the unknown LCAF type is ignored when processing the packet.

Otherwise, if the WG prefers to leave things as they are, that’s fine as well. Just please do not reopen rfc6833bis :)

Thanks!
Alberto

From: Alvaro Retana <[email-masked]>
Date: Thursday, April 14, 2022 at 1:40 PM
To: [email-masked] list <[email-masked]>
Cc: Luigi Iannone <[email-masked]>, Dino Farinacci <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: Unknown LCAF Types (?) (draft-ietf-lisp-vendor-lcaf)
Hi!

OTOH, even if rfc6833bis is the base specification, rfc8060 is an optional extension…. The problem is one of references and document status:

rfc8060 is an Experimental document — the current reference in rfc6833bis is Informative, which is ok because there’s just a general reference to the AFI — “LCAF-Type MUST” makes the relationship to rfc8060 Normative and changes the behavior of rfc8060 implementations, so we should change the reference type and formally update rfc8060, which results in a downref, which requires community approval (new IETF LC), which requires the IESG to consider the downref registry, . . .

Ideally, rfc8060 would have included that one extra sentence: “an unrecognized LCAF-Type MUST be dropped”.

(1) Let it be.  rfc8060 is Experimental, people “experimenting” with it can figure it out, and when/if the document goes on the Standards Track we can add the text.  I know there are production deployments, but these are mostly controlled (people shouldn’t see unknown types).

(2) Use lisp-vendor-lcaf, which adds a new Type, to formally update rfc8060 on what needs to be done if an unknown Type is received.  Both documents are Experimental and lisp-vendor-lcaf is in line to be approved next week by the IESG, so there are no cumbersome process issues.

So…what does the WG want to do?  reopen rfc6833bis, nothing, or use lisp-vendor-lcaf

[FWIW, my personal preference (as WG participant) is to use lisp-vendor-lcaf.]

Thanks!

Alvaro.

On April 13, 2022 at 3:02:28 PM, Dino Farinacci ([email-masked]<mailto:[email-masked]>) wrote:
Just confirm, the behavior is not specified in rfc8060, right?  It seems to me that it would be good to specify it somewhere and draft-ietf-lisp-vendor-lcaf looks as good a place as any - do you agree?

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 14 Apr 2022 17:55:06 +0200

Hi,

I stick to my answer to Christer, we should update 8060 ;-)

Ciao

L.

> On 14 Apr 2022, at 13:39, Alvaro Retana <[email-masked]> wrote:
> 
> Hi!
> 
> On April 13, 2022 at 3:02:28 PM, Dino Farinacci ([email-masked] <mailto:[email-masked]>) wrote:
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 14 Apr 2022 13:00:07 -0700

> I don’t think any of us wants to reopen rfc6833bis at this point. <sigh>

Okay.

> (1) Let it be.  rfc8060 is Experimental, people “experimenting” with it can figure it out, and when/if the document goes on the Standards Track we can add the text.  I know there are production dep…

Right and true.

> (2) Use lisp-vendor-lcaf, which adds a new Type, to formally update rfc8060 on what needs to be done if an unknown Type is received.  Both documents are Experimental and lisp-vendor-lcaf is in line…

So add the sentence to lisp-vendor-lcaf since we still have time. This is fine with me.

> So…what does the WG want to do?  reopen rfc6833bis, nothing, or use lisp-vendor-lcaf

I vote for lisp-vendor-lcaf.

> [FWIW, my personal preference (as WG participant) is to use lisp-vendor-lcaf.]

Well that's two people in sync. ;-)

Dino