Joel,
Yes, I think you do have the right end of the question, and that new text looks
ok, as the previous sentence introduces the gratuitous ARP.
To summarize, we've decided to address two of the three concerns from the review
of -06. The third concern that will not be addressed is:
a) the alternative of statically allowing all source addresses through all
teamed/aggregated links (decouples SAVI state from link
teaming/aggregation
state) should also be mentioned,
I'm satisfied with this outcome.
Thanks,
--David
-----Original Message-----
From: Joel M. Halpern [mailto:jmh(_at_)joelhalpern(_dot_)com]
Sent: Friday, March 29, 2013 6:08 PM
To: Ted Lemon
Cc: Black, David; McPherson, Danny; savi(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org; gen-
art(_at_)ietf(_dot_)org; Jean-Michel Combes;
joel(_dot_)halpern(_at_)ericsson(_dot_)com
Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06
I have a draft version with this correction.
David, would adding:
When such a move
is done without changing the MAC address, the SAVI switches
will need to update their state. While the ARP may be
helpful,
traffic detection, switch based neighbor solicitation,
interaction with orchestration system, or other means may be
used.
to the end of 5.2.3 address your concern? I am not sure whether I have
the right end of the question here, given that SAVI can not create new
protocol.
Yours,
Joel
On 3/27/2013 10:56 PM, Ted Lemon wrote:
On Mar 27, 2013, at 12:45 PM, Joel Halpern Direct
<jmh(_dot_)direct(_at_)joelhalpern(_dot_)com> wrote:
Then it will be done. I will wait for the AD to decide what other changes
are needed, and then will either make this change or include it in an RFC
Editor note.
Old:
If the bridging topologies which connects the switches changes, or
if LACP [IEEE802.3ad] changes which links are used to deliver
traffic, the switch may need to move the SAVI state to a different
port, are the state may need to be moved or reestablished on a
different switch.
New:
If the bridging topologies which connects the switches changes, or
if LACP [IEEE802.3ad], VRRP, or other link management
operations, change which links are used to deliver
traffic, the switch may need to move the SAVI state to a different
port, are the state may need to be moved or reestablished on a
different switch.
I think you probably meant "or", not "are", in the second word of the
second-to-last line of the new text.
As far as I am concerned, given that David is happy with your recent change,
I'm happy with it too. However, since you are asking, if you were willing to
also accommodate David's other request (see below) by adding some text to the
document in section 5, that would be an added bonus:
A paragraph has been added to 5.2.3 to address all three of the above
concerns. I guess that's ok, but I would have liked to see some text
pointing out that a MAC move can be detected by the switches and used to
update SAVI state about which port(s) a MAC is accessed through.
So if you can do this, it would be much appreciated; if you can't do it, I
think the document is valuable enough to move forward without this additional
work.