Subject: [trill] Alvaro Retana's Discuss on draft-ietf-trill-arp-optimization-06: (with DISCUSS)

From: "Alvaro Retana" <[email-masked]>
Date: Wed, 06 Jul 2016 20:13:45 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-arp-optimization-06: 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-trill-arp-optimization/

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

I know this is an optional optimization, as described by the “MAY” in the
Introduction.  However, some of the other normative language is not as
strong as it should be to clearly specify the required behavior (if the
mechanisms are being used), cause confusion, or is simply out of place.

1. In 3.1 (Get Sender's IP/MAC Mapping Information for Non-zero IP) the
text says that the “RBridge MAY use different strategies to do so”.  That
“MAY” contradicts the “SHOULD” used before it, which directs the RBridge
to verify a duplicate address.  s/MAY/may

2. Still in 3.1: “…the RBridge SHOULD verify if a duplicate IP address
has already been in use…”  What are the reasons where the RBridge would
not verify this situation?  IOW, why is this “SHOULD” not a “MUST”?

3. I’m confused as to whether the APPsub-TLV is required or not.  The
source of my confusion comes from Section 3.3 (Determine How to Handle
the ARP/ND Response) which says that “R2 SHOULD initiate a link state
update to inform all the other RBridges of the target's location…The
update message can be carried by an IA APPsub-TLV [IA-draft]…”  This text
seems to say that the APPsub-TLV SHOULD be used to carry the information
— but text in Section 2 (IP/MAC Address Mappings) sounds to me as if the
use of the APPsub-TLV is optional: “If the RBridge has extracted the
sender's IP/MAC address pair from the received data packet (either ARP or
ND), it MAY save the information and use the IA APPsub-TLV…”  Also, 3.1
and 3.2 both say that an “RBridge MAY use the IA APPsub-TLV”.  And
finally the Security Considerations section seems to recommend using it… 
Maybe it’s just me, but please clarify.  [BTW, if it is required, then I
think that both the IA-draft and DirMech references should be
Normative.]

4. In Section 2 (IP/MAC Address Mappings) the “MAY” in the following
sentence is out of place since that is already the function of the
confidence (as described in draft-ietf-trill-ia-appsubtlv and RFC6325):
“A different confidence level MAY also be used to indicate the
reliability of the mapping information.”

5. In Section 3.2 (Determine How to Reply to ARP/ND), both options (?) a
and b say that the “RBridge MAY take one…”.  If the RBridge selected that
option, then I think the action is no longer optional.  s/MAY/MUST

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 29 Jul 2016 19:19:06 -0400

Hi Alvaro,

On Wed, Jul 6, 2016 at 11:13 PM, Alvaro Retana <[email-masked]>
wrote:
> ...
> I know this is an optional optimization, as described by the “MAY”
> in the Introduction.  However, some of the other normative language
> is not as strong as it should be to clearly specify the required
> behavior (if the mechanisms are being used), cause confusion, or is
> simply out of place.
>
> 1. In 3.1 (Get Sender's IP/MAC Mapping Information for Non-zero IP)
> the text says that the “RBridge MAY use different strategies to do
> so”.  That “MAY” contradicts the “SHOULD” used before it, which
> directs the RBridge to verify a duplicate address.  s/MAY/may

OK.

> 2. Still in 3.1: “…the RBridge SHOULD verify if a duplicate IP
> address has already been in use…” What are the reasons where the
> RBridge would not verify this situation?  IOW, why is this “SHOULD”
> not a “MUST”?

If the network manager's philosophy is have the network behave as if
the relevant set of end stations were on a single link and just
believe an ARP it received, it might not do anything to try to verify
conflicting prior attachment information.

> 3. I’m confused as to whether the APPsub-TLV is required or not.
> The source of my confusion comes from Section 3.3 (Determine How to
> Handle the ARP/ND Response) which says that “R2 SHOULD initiate a
> link state update to inform all the other RBridges of the target's
> location…The update message can be carried by an IA APPsub-TLV
> [IA-draft]…” This text seems to say that the APPsub-TLV SHOULD be
> used to carry the information — but text in Section 2 (IP/MAC
> Address Mappings) sounds to me as if the use of the APPsub-TLV is
> optional: “If the RBridge has extracted the sender's IP/MAC address
> pair from the received data packet (either ARP or ND), it MAY save
> the information and use the IA APPsub-TLV…” Also, 3.1 and 3.2 both
> say that an “RBridge MAY use the IA APPsub-TLV”.  And finally the
> Security Considerations section seems to recommend using it… Maybe
> it’s just me, but please clarify.  [BTW, if it is required, then I

I agree that the wording should be clarified.

RBridges are interested in the nickname of the RBridge to which some
destination address is attached, since RBridges route on nickname. This
information can be communicated for IP addresses with IP reachability
link state TLVs and for MAC addresses with MAC reachability link state
TLVs (each genrally within the scope of a VLAN (or FGL)). However, for
ARP/RARP/ND optimization, you generally want to know the MAC<->IP
mapping which is absent with separate MAC and IP reachability.

The IA APPsub-TLV is, as far as I know, the only link state data
format that can be used to bind together the MAC and IP address(es)
for an interface (port), as well as providing the nickname of the
RBridge to which that interface is attached and possibly other
information. Thus, if you are to communicate information useful to,
for example, provide a locally created response to an ARP, you need to
use IA APPsub-TLV.

> confidence (as described in draft-ietf-trill-ia-appsubtlv and
> RFC6325): “A different confidence level MAY also be used to indicate
> the reliability of the mapping information.”

That should be a lower case "may" (or perhaps "can" or something else).

> 5. In Section 3.2 (Determine How to Reply to ARP/ND), both options
> (?) a and b say that the “RBridge MAY take one…”.  If the RBridge
> selected that option, then I think the action is no longer optional.
> s/MAY/MUST

OK.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]