Subject: [trill] Suresh Krishnan's Discuss on draft-ietf-trill-arp-optimization-06: (with DISCUSS and COMMENT)

From: "Suresh Krishnan" <[email-masked]>
Date: Tue, 05 Jul 2016 21:36:13 -0700

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

* After the ingress RBridge learns the mapping between an IPv6 address
and a MAC address how is the liveness being tested/maintained? i.e. If a
"learnt" target IP goes off link and the Rbridge keeps responding to NS
messages wouldn't it make troubleshooting a nightmare?
* Section 3.2 case a): There is no guidance as to why or when an Rbridge
would pick cases a1..a5. e.g. When a SEND NS is received only option a2
can work and all others will fail.  
* Section 3.2 case a.1): What should be the source IPv6 address of the NA
generated by the ingress RBridge? Will this be an address of the target
of the NS or one of the ingress Rbridge that responds?
* Section 3.2: How is an ND message where the target IP is not known
handled? This case seems to be left out.

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

* The draft contains no discussion of SEND (RFC3971) in the Security
considerations section when talking about forged ND messages.

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 7 Jul 2016 10:04:27 -0400

Hi Suresh,

Thanks for your insightful comments. See below.

On Wed, Jul 6, 2016 at 12:36 AM, Suresh Krishnan
<[email-masked]> wrote:
> ...

There needs to be appropriate liveness determination. There are a lot
of ways this could be done but rather than going into this here, I
think that a section should be added to the document on this topic.
(Exactly what would happen if and IPv6 end station crashed or got
disconnected would depend on many factors. In some cases the edge
RBridge would know right away if it was a point-to-point link that
went down. But optimized ARP/NS responses should stop not long after
the end station becomes non-responsive to ARP/NS messages it receives
directly.)

> can work and all others will fail.

Yes, the restrictions on SEND should be noted. Otherwise, the choice
is a matter of local policy.

> of the NS or one of the ingress Rbridge that responds?

There is no requirement in the TRILL protocol that an RBridge have
either an IPv4 or IPv6 address (although as a practical matter, they
probably almost always do). So the source IPv6 address should be that
of the target.

> handled? This case seems to be left out.

If the target IP is "unknown", then generally you would flood based on
the destination MAC within the VLAN/Label of the traffic but if you
were in an environment with complete directory information and you
know that IP did not exist, I think you could just discard the message.

Yes, I think that should be mentioned.

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

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 13 Jul 2016 03:33:32 +0000

Hi Donald,
   Your proposed changes look good to me. I will clear once the new version 
gets posted with the changes,

Thanks
Suresh