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

[Donald Eastlake <[e-mail]>]

Hi Suresh,

Thanks for your insightful comments. See below.

On Wed, Jul 6, 2016 at 12:36 AM, Suresh Krishnan
<[e-mail]> wrote:
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-trill-arp-optimization-06: Discuss
>
> ...
>
> ----------------------------------------------------------------------
> 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?

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

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

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

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

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.

> * Section 3.2: How is an ND message where the target IP is not known
> 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.

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

Yes, I think that should be mentioned.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]