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
