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

["Alberto Rodriguez-Natal (natal)" <[e-mail]>]

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 <[e-mail]>
Date: Thursday, April 14, 2022 at 1:40 PM
To: [e-mail] list <[e-mail]>
Cc: Luigi Iannone <[e-mail]>, Dino Farinacci <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Unknown LCAF Types (?) (draft-ietf-lisp-vendor-lcaf)
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 ([e-mail]<mailto:[e-mail]>) 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?

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

[cid:39C8418E-4AE3-4146-B284-C75E82B34FC1]

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