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 protected]) 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:


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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to