Re: Robert Wilton's No Objection on draft-ietf-6man-grand-06: (with COMMENT)

[Alexandre Petrescu <[e-mail]>]

Le 01/07/2021 à 14:08, Jen Linkova a écrit :
> Hi Robert,
> 
> On Thu, Jul 1, 2021 at 6:25 PM Robert Wilton via Datatracker
> <[e-mail]> wrote:
>> (1) I wasn't really familiar with the term "off-link" and I was wondering
>> whether it's definition should be imported here, although I note that ND does
>> define and use this term, so readers familiar with the ND RFC would presumably
>> be familiar with it.
> 
> Yes,  the idea of off-link and on-link addresses/communication is kind
> of fundamental for ND.
> I'll add the following text to the Terminology section:
> "On-link address: an address that is assigned to an interface on a
> specified link. See Section 2.1 of [RFC4861] for detailed definition.
> Off-link: the opposite of "on-link". See Section 2.1 of [RFC4861] for
> detailed definition."
> 
> Would it make it better?

Aside from the conversation above that I agree with,  and aside of the 
fact that I agree that RFC 4861 does define the term "off-link" too by 
opposing it to a better defined "on-link" term, I must say that I never 
used or heard in practice people talking about off-link or on-link 
addresses.

If one wants to talk about off-link or on-link addresses then one talks 
about neighbors or not neighbors.

We around me usually talk casually about link-local addresses (adresses 
'lien', fr.), but we never talk about off-link or on-link addresses.

Then, there is the use of the term 'on-link' in RFC4861 which is at 
times glued to 'prefixes', even though it is formally defined to mean 
'addresses'.
For example, a full expansion of this RFC4861 text:
"These options specify the prefixes that are on-link"
would actually mean
"These options specify the prefixes that are on-link, i.e. addresses 
assigned to an interface on a specified link"
which is somehow difficult to understand.

The most confusing is probably the expansion of this text:
"L              1-bit on-link flag."
which, when expanded, it would mean
"L              1-bit on-link addresses flag"
when it is, in fact, a flag about prefixes in PIOs, and not about 
addresses.  These prefixes are often used for other operations than just 
forming addresses.  It is thus difficult to grasp.

Probably this could be solved if in the definition of 'on-link' in 
RFC4861 it said that it could also be a prefix, not just an address.

This 'on-link' and 'off-link' discussion relates a lot to the 
difficulties we have in suggesting at IETF that a new extension is 
needed to tell that a prefix advertised on a link might not be for that 
link to be used for SLAAC, but for putting in a routing table entry.  A 
little bit similar to RFC4191's RIOs.

But when told that the RIO of RFC4191 might be appropriate for the V2V 
case that I needed I always reply that what we need is an RIO that is 
always outside the link (I dont use the term 'off-link'), and always at 
least 2-hops away, never 1-hop away.  SO there I dont use either the 
on/off-link terms.

Maybe it's just me...

End of parenthesis.

Alex

> 
>> (2) I actually found the normative text updating RFC4861 in section 6.1.1 to
>> not be that readable, and I had to scan it a couple of times to spot the
>> distinction between router and host.  Possibly laying out the text slightly
>> differently would make the distinction between host and router behaviour more
>> obvious.  E.g.,
>>
>>     When a valid Neighbor Advertisement is received (either solicited or
>>     unsolicited), the Neighbor Cache is searched for the target's entry.
>>     If no entry exists:
>>
>>         Hosts SHOULD silently discard the advertisement.  There is no
>>         need to create an entry if none exists, since the recipient has
>>         apparently not initiated any communication with the target.
>>
>>         Routers SHOULD create a new entry for the target address with
>>         the link-layer address set to the Target link-layer address
>>         option (if supplied).  The entry's reachability state MUST be
>>         set to STALE.  If the received Neighbor Advertisement does not
>>         contain the Target link-layer address option the advertisement
>>         SHOULD be silently discarded.
> 
> Done, -07 will have the updated text, thanks for the suggestion!
>