Subject: [lisp] Jari Arkko's Discuss on draft-ietf-lisp-lcaf-17: (with DISCUSS and COMMENT)

From: "Jari Arkko" <[email-masked]>
Date: Thu, 13 Oct 2016 01:48:49 -0700

Jari Arkko has entered the following ballot position for
draft-ietf-lisp-lcaf-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-lcaf/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for writing this doc. I plan to recommend its approval, but there
were a couple of things that I think should be fixed for clarity before
issuing the RFC. First, I agree with Peter Yee who did a Gen-ART review
on this document:

> Page 6, Rsvd2 definition: the definition both says "reserved for future
use"
> and then says some types actually use it.  That sounds like present
use.
> And to generically say that it should be sent as zero and ignored, but
then
> to give uses (such as Type 2)  for it  is confusing.  I suggest
rethinking
> the wording here.

The type that seems to differ from the "ignore" advice in Section 3 is
Type 14. Perhaps you can reword somehow, or name the Rsvd2 field to
Flags, and let the Subsections define that as "set to 0 and ignore on
receipt". Or something along those lines?

I also agree with this comment and believe the text should be corrected:

> Page 6, Length definition: there's mention of a "Reserved" field
that's
> included in the minimum length of 8 bytes that are not part of the
length
> value.  Since there are actually Rsvd1 and Rsvd2 fields in the generic
> version of the LCAF and sometimes even Rsvd3 and Rsvd4 fields when
using
> specific Types, it might be better to spell out which reserved fields
(Rsvd1
> and Rsvd2) are meant here rather than giving the field a summary name
that
> doesn't actually appear in the format.  This is also important because
any
> Rsvd3 and Rsvd4 fields are included in the Length field, so using a
generic
> "Reserved" description is ambiguous at best.

And this seems like a bug as well:

> Page 13, RTR RLOC Address definition, 4th sentence: The ability to
determine
> the number of RTRs encoded by looking at the value of the LCAF length
> doesn't seem feasible.  3 IPv4 RTR RLOCs will produce the same LCAF
Length
> as 1 IPv6 RTR RLOC.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Subsections under Section 4 treat some of the fields in different ways.
For instance, in most cases the subsections do not indicate anything
about the base fields, but for instance Subsection 4.9 does say something
about Rsvd1 and Rsvd2:

   Rsvd{1,2,3,4}:  must be set to zero and ignore on receipt.

This text was raised as an issue by Peter as well:

      When there are no RTRs
      supplied, the RTR fields can be omitted and reflected by the LCAF
      length field or an AFI of 0 can be used to indicate zero RTRs
      encoded.

Why are we giving two options? Or is this a
be-conservative-what-you-send-but-liberal-in-what-you-accept situation?

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 14 Oct 2016 06:21:11 -0700

> issuing the RFC. First, I agree with Peter Yee who did a Gen-ART review

Thanks for your comments Jari. See responses inline.

> receipt". Or something along those lines?

I have suggested (and rewritten) that Rsvd2 be sent as 0 and ignored on receipt throughout.

>> "Reserved" description is ambiguous at best.

When the Length field is 0, it means that no more data follows (for the LCAF encoding), however the first 8 bytes of the LCAF are still included in the message. So I am trying to discuss the minimum length of the message (which is 8 bytes).

I have fixed the text to refer to Rsvd1 and Rsvd2 instead of “Reserved” since there is nothing labled “Reserved”.

>> doesn't seem feasible.  3 IPv4 RTR RLOCs will produce the same LCAF

It is not a bug. The number of addresses encoded can only be determined by parsing each one. And there is no value to include a count since you can compute while parsing (since you have to parse the message to retrieve and store variable length addresses).

I will make consistent that Rsvd1 and Rsvd2 fields are described up front and Rsvd3/Rsvd4 in the specific type definitions, since they do not appear in all definitions.

> be-conservative-what-you-send-but-liberal-in-what-you-accept situation?

Because the message can be truncated (to reduce size of message), or the RTR field can be encoded with an AFI=0 (which means no RTR address follows).

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 14 Oct 2016 06:20:29 -0700

Dino

---

From: Jari Arkko <[email-masked]>
Date: Fri, 14 Oct 2016 22:07:37 +0300

Thanks. All seems reasonable. I cleared, and will let you update the doc as instructed by your AD.

Jari