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

[Dino Farinacci <[e-mail]>]

> 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:

Thanks for your comments Jari. See responses inline.

> 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 have suggested (and rewritten) that Rsvd2 be sent as 0 and ignored on receipt throughout.

> 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.

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”.

> 
> 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.

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).

> ----------------------------------------------------------------------
> 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.

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.

> 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?

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