Antiquity lives on. This draft is back from the dead.
Somehow, it made it to the IESG review without my finishing addressing
your comments. My apologies for that. I am trying to finish this off.
You will see Monday afternoon a new draft in the repository, with a
section 4.1.2 on LACP, and a new paragraph in 5.2.3 to note the issues
around (virtual) host relocation.
I hope that these properly address your old but very well-taken comments.
(I can send it to you if you want itsooner.)
Thank you,
Joel M. Halpern
On 5/16/2011 1:09 PM, Joel M. Halpern wrote:
I can plan to make these changes at the end of the last call.
Joel
On 5/16/2011 12:56 PM, [email protected] wrote:
Joel,
I think the LACP discussion could be added to 4.1.1.
I also think that there's a general theme that needs to be covered
across all of 4.1.1 - 4.1.4: When there are multiple traffic egress
points from a domain (4.1.1 - 4.1.4 cover four different types of
domains), the SAVI checks on all the egresses should be coordinated
and consistent in order to avoid surprises when the traffic switches
to a different egress point.
Thanks,
--David
-----Original Message-----
From: Joel M. Halpern [mailto:[email protected]]
Sent: Monday, May 16, 2011 11:29 AM
To: Black, David
Cc: [email protected]; [email protected];
[email protected]; [email protected];
[email protected]; [email protected]; [email protected]
Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-05
Looking at the draft more carefully (when I am more awake, sorry), I
think what you are asking is that more text be put in section 4.1, maybe
a subsection? That additional text would talk about placement on a
switch that is not directly attached to the client, but is not as far
upstream as the first hop router? That text would include mention of
the effect of spanning tree variation and LACP path changes.
Sorry I was dense,
Joel
On 5/15/2011 9:45 PM, [email protected] wrote:
Joel,
If LACP is running active-passive across links to two different
switches, there may be no physical
network node common to the currently active and currently passive
paths for some traffic. If SAVI
is set up poorly, a switch to the currently passive link could remove
validation checks or black-
hole traffic that was flowing on the previously active link. For
example, binding an IP address to a
single port or ports on a single switch is insufficient in such an
environment (address validation
binding needs to span switches).
The material in 5.2.4 on Multi-LAN Hosts looks like a starting point
- wrt SAVI, active-passive
link aggregation across multiple switches can be a way to get into
that sort of trouble on a single
LAN (!). Beyond that, I think the notion that SAVI checks should be
consistent across alternate
paths for the same traffic is applicable at other scopes, e.g., all
egresses from a multi-homed
network to the ISP networks involved.
Thanks,
--David
-----Original Message-----
From: Joel M. Halpern [mailto:[email protected]]
Sent: Friday, May 13, 2011 11:28 AM
To: Black, David
Cc: [email protected]; [email protected];
[email protected]; [email protected];
[email protected]; [email protected];
[email protected]
Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-05
Thank you David.
I think I understand the second part of your comment (about
multi-instance hosts), and will have to look at the document more
to see
how to address that.
I am not sure I understand what the question is regarding the LACP /
link group issue. Is this really different from the issues that arise
whenever the SAVI functionality is not on the leaf switch? Where
in the
document do you think it would help to discuss this?
Thank you,
Joel
On 5/13/2011 1:03 AM, [email protected] wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-savi-threat-scope-05
Reviewer: David L. Black
Review Date: 12 May 2011
IETF LC End Date: 18 May 2011
Summary: This draft is on the right track, but has open issues,
described in the review.
This draft discusses the threats and deployment environment for IP
source
address validation with particular attention to finer-grain
validation that
could be used within a network to validate IP addresses closer to
the sources
of network traffic than ingress to an ISP's network.
Major issues:
There is no discussion of link teaming or aggregation (e.g., via
LACP); this
may affect source address validation functionality by requiring
the same
validation checks on all aggregated ports. An important case to
discuss
is where the aggregated host links are connected to ports on
different switches
(e.g., in an active/passive configuration).
The discussion of multi-instance hosts in section 5.2.3 is incomplete
in several important aspects:
(1) Some of the software switch implementations are single
instance switches
whose implementation is distributed across multiple physical
servers. This
results in concerns similar to the link aggregation discussion above.
(2) Live migration of virtual machines among physical servers causes
relocation of MAC addresses across switch ports. A so-called
"gratuitous ARP"
is often used to inform the network of the MAC address move;
port-based
source address validation information needs to move in response to
such ARPs.
(3) MAC address relocation is also used as a failure recovery
technique; the
surviving hardware element (e.g., host in a cluster) takes over
the MAC
addresses of the failed hardware; like the previous case, a
"gratuitous ARP"
is a common means of informing the network that the MAC address
has moved,
and source address validation information needs to move in
response to it.
Minor issues:
There doesn't seem to be much discussion of dynamic network
reconfiguration,
which may change traffic egress points. VRRP may be a useful
example to
discuss beyond the typical routing protocol updates to forwarding
tables.
Nits/editorial comments:
idnits 2.12.11 ran clean.
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[email protected] Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
savi mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/savi
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
