From david.black@emc.com Mon Mar 25 18:04:46 2013 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECC421F8765; Mon, 25 Mar 2013 18:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-lmhBku-vUk; Mon, 25 Mar 2013 18:04:45 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7622C21F875A; Mon, 25 Mar 2013 18:04:43 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2Q14UVJ012354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Mar 2013 21:04:31 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Mon, 25 Mar 2013 21:04:11 -0400 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2Q14AxJ009683; Mon, 25 Mar 2013 21:04:10 -0400 Received: from mx15a.corp.emc.com ([169.254.1.81]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Mon, 25 Mar 2013 21:04:09 -0400 From: "Black, David" To: "McPherson, Danny" , Fred Baker , "joel.halpern@ericsson.com" , "gen-art@ietf.org" Date: Mon, 25 Mar 2013 21:04:08 -0400 Thread-Topic: Gen-ART review of draft-ietf-savi-threat-scope-06 Thread-Index: AcwRKxLMGPOwf18pRUizv8st+VLKC4QxHuTA Message-ID: <8D3D17ACE214DC429325B2B98F3AE71293AEEDC8@MX15A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "ietf@ietf.org" , "Black, David" , "savi@ietf.org" , Ted Lemon , Jean-Michel Combes Subject: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 01:04:46 -0000 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see=20 http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-savi-threat-scope-06 Reviewer: David L. Black Review Date: March 27, 2013 IESG Telechat Date: (if known) Summary: This draft is on the right track, but has open issues, described i= n the review. Looking at the original Gen-ART review of the -05 draft and checking the di= ffs between -05 and -06, the issues raised by that review have only been partia= lly addressed: > There is no discussion of link teaming or aggregation (e.g., via LACP); t= his > 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). This is partially addressed on 4.1.2 (new section in -06), but only in term= s of moving validation state when something like LACP reconfigures. This has= a couple of shortcomings: a) the alternative of statically allowing all source addresses through all teamed/aggregated links (decouples SAVI state from link teaming/aggregatio= n state) should also be mentioned, and b) the new text implies that LACP is the only way to cause this situation -= it's not, so LACP should be used as an example. VRRP is another example. > (1) Some of the software switch implementations are single instance switc= hes > whose implementation is distributed across multiple physical servers. Th= is > results in concerns similar to the link aggregation discussion above. I don't think this has been addressed, but the notion of single-instance sw= itches could be added to the generalization of the new text in 4.1.2. > (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 A= RPs. > > (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 A= RP" > 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: >=20 > There doesn't seem to be much discussion of dynamic network reconfigurati= on, > which may change traffic egress points. VRRP may be a useful example to > discuss beyond the typical routing protocol updates to forwarding tables. A paragraph has been added to 5.2.3 to address all three of the above conce= rns. I guess that's ok, but I would have liked to see some text pointing out tha= t a MAC move can be detected by the switches and used to update SAVI state abou= t which port(s) a MAC is accessed through. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Friday, May 13, 2011 1:03 AM > To: McPherson, Danny; Fred Baker; joel.halpern@ericsson.com; gen-art@ietf= .org > Cc: Black, David; Christian Vogt; Jean-Michel Combes; Jari Arkko; > savi@ietf.org > Subject: Gen-ART review of draft-ietf-savi-threat-scope-05 >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-savi-threat-scope-05 > Reviewer: David L. Black > Review Date: 12 May 2011 > IETF LC End Date: 18 May 2011 >=20 > Summary: This draft is on the right track, but has open issues, described= in > the review. >=20 > This draft discusses the threats and deployment environment for IP source > address validation with particular attention to finer-grain validation th= at > could be used within a network to validate IP addresses closer to the sou= rces > of network traffic than ingress to an ISP's network. >=20 > Major issues: >=20 > There is no discussion of link teaming or aggregation (e.g., via LACP); t= his > 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). >=20 > The discussion of multi-instance hosts in section 5.2.3 is incomplete > in several important aspects: >=20 > (1) Some of the software switch implementations are single instance switc= hes > whose implementation is distributed across multiple physical servers. Th= is > results in concerns similar to the link aggregation discussion above. >=20 > (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 A= RPs. >=20 > (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 A= RP" > 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= . >=20 > Minor issues: >=20 > There doesn't seem to be much discussion of dynamic network reconfigurati= on, > which may change traffic egress points. VRRP may be a useful example to > discuss beyond the typical routing protocol updates to forwarding tables. >=20 > Nits/editorial comments: >=20 > idnits 2.12.11 ran clean. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 From david.black@emc.com Mon Mar 25 18:08:29 2013 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD7521F8678; Mon, 25 Mar 2013 18:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvAjlMWKGNIB; Mon, 25 Mar 2013 18:08:28 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB5A21F866E; Mon, 25 Mar 2013 18:08:27 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2Q18Nal005408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Mar 2013 21:08:23 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 25 Mar 2013 21:08:06 -0400 Received: from mxhub35.corp.emc.com (mxhub35.corp.emc.com [10.254.93.83]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2Q185MN026399; Mon, 25 Mar 2013 21:08:05 -0400 Received: from mx15a.corp.emc.com ([169.254.1.81]) by mxhub35.corp.emc.com ([::1]) with mapi; Mon, 25 Mar 2013 21:08:05 -0400 From: "Black, David" To: "Black, David" , "McPherson, Danny" , Fred Baker , "joel.halpern@ericsson.com" , "gen-art@ietf.org" Date: Mon, 25 Mar 2013 21:08:04 -0400 Thread-Topic: Gen-ART review of draft-ietf-savi-threat-scope-06 Thread-Index: AcwRKxLMGPOwf18pRUizv8st+VLKC4QxHuTAAADx9PA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE71293AEEDCA@MX15A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71293AEEDC8@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71293AEEDC8@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "ietf@ietf.org" , "savi@ietf.org" , Ted Lemon , Jean-Michel Combes Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 01:08:29 -0000 > Review Date: March 27, 2013 Copy/paste glitch - that should be March 25 for obvious reasons ... Thanks, --David > -----Original Message----- > From: Black, David > Sent: Monday, March 25, 2013 9:04 PM > To: McPherson, Danny; Fred Baker; joel.halpern@ericsson.com; gen-art@ietf= .org > Cc: Jean-Michel Combes; Ted Lemon; savi@ietf.org; Black, David; ietf@ietf= .org > Subject: Gen-ART review of draft-ietf-savi-threat-scope-06 >=20 > I have been selected as the General Area Review Team (Gen-ART) reviewer > for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >=20 > Please wait for direction from your document shepherd or > AD before posting a new version of the draft. >=20 > Document: draft-ietf-savi-threat-scope-06 > Reviewer: David L. Black > Review Date: March 27, 2013 > IESG Telechat Date: (if known) >=20 > Summary: This draft is on the right track, but has open issues, described= in > the review. >=20 > Looking at the original Gen-ART review of the -05 draft and checking the = diffs > between -05 and -06, the issues raised by that review have only been part= ially > addressed: >=20 > > There is no discussion of link teaming or aggregation (e.g., via LACP);= this > > may affect source address validation functionality by requiring the sam= e > > validation checks on all aggregated ports. An important case to discus= s > > is where the aggregated host links are connected to ports on different > > switches (e.g., in an active/passive configuration). >=20 > This is partially addressed on 4.1.2 (new section in -06), but only in te= rms > of moving validation state when something like LACP reconfigures. This h= as a > couple of shortcomings: > a) the alternative of statically allowing all source addresses through a= ll > teamed/aggregated links (decouples SAVI state from link > teaming/aggregation > state) should also be mentioned, and > b) the new text implies that LACP is the only way to cause this situation= - > it's > not, so LACP should be used as an example. VRRP is another example. >=20 > > (1) Some of the software switch implementations are single instance swi= tches > > whose implementation is distributed across multiple physical servers. = This > > results in concerns similar to the link aggregation discussion above. >=20 > I don't think this has been addressed, but the notion of single-instance > switches > could be added to the generalization of the new text in 4.1.2. >=20 > > (2) Live migration of virtual machines among physical servers causes > > relocation of MAC addresses across switch ports. A so-called "gratuito= us > 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 mov= ed, > > 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 reconfigura= tion, > > which may change traffic egress points. VRRP may be a useful example t= o > > discuss beyond the typical routing protocol updates to forwarding table= s. >=20 > 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 t= hat a > MAC move can be detected by the switches and used to update SAVI state ab= out > which port(s) a MAC is accessed through. >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Black, David > > Sent: Friday, May 13, 2011 1:03 AM > > To: McPherson, Danny; Fred Baker; joel.halpern@ericsson.com; gen- > art@ietf.org > > Cc: Black, David; Christian Vogt; Jean-Michel Combes; Jari Arkko; > > savi@ietf.org > > Subject: Gen-ART review of draft-ietf-savi-threat-scope-05 > > > > I am the assigned Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at > > . > > > > 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, describ= ed in > > the review. > > > > This draft discusses the threats and deployment environment for IP sour= ce > > 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 sam= e > > validation checks on all aggregated ports. An important case to discus= s > > 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 swi= tches > > 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 "gratuito= us > 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 mov= ed, > > 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 reconfigura= tion, > > which may change traffic egress points. VRRP may be a useful example t= o > > discuss beyond the typical routing protocol updates to forwarding table= s. > > > > Nits/editorial comments: > > > > idnits 2.12.11 ran clean. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293= -7786 > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > From Ted.Lemon@nominum.com Mon Mar 25 18:37:57 2013 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3F121F84A9; Mon, 25 Mar 2013 18:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hqbg+v95acw; Mon, 25 Mar 2013 18:37:56 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDF621F849C; Mon, 25 Mar 2013 18:37:55 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUVD78ruWkqholvdmxNNqRhPSYnsidaPD@postini.com; Mon, 25 Mar 2013 18:37:55 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B34E11B806F; Mon, 25 Mar 2013 18:37:54 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9B23C19005C; Mon, 25 Mar 2013 18:37:54 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 25 Mar 2013 18:37:54 -0700 From: Ted Lemon To: "Black, David" Thread-Topic: Gen-ART review of draft-ietf-savi-threat-scope-06 Thread-Index: AcwRKxLMGPOwf18pRUizv8st+VLKC4QxHuTAABCsJwA= Date: Tue, 26 Mar 2013 01:37:54 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077511F644@mbx-01.win.nominum.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71293AEEDC8@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71293AEEDC8@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7015540D083D1B41BB2B7299DD9E5DAC@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "McPherson, Danny" , "savi@ietf.org" , "ietf@ietf.org" , "gen-art@ietf.org" , Jean-Michel Combes , "joel.halpern@ericsson.com" Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 01:37:57 -0000 On Mar 25, 2013, at 9:04 PM, "Black, David" wrote: > Summary: This draft is on the right track, but has open issues, described= in the review. While I identified the same issue you did with switching systems that do li= nk aggregation and other magic, I think that the document is useful whether= this is fixed or not. It's true that it doesn't have a full section that = talks specifically about this problem, but I think it's unlikely that the a= uthors are going to add one=97when I mentioned it to Joel, he didn't expres= s excitement at the prospect. I think Fred's response, while a little salty, accurately represents the si= tuation: the working group produced this document, the document does what i= t's supposed to do, one could continue to polish it indefinitely, but then = the document would never get published. Remembering that this is an informational draft, which does a pretty good j= ob of informing the reader about the problem space, is it your opinion that= the issues you have raised _must_ be addressed before the document is publ= ished, or do you think the document is still valuable even if no further te= xt is added to address your concern? From david.black@emc.com Tue Mar 26 16:45:32 2013 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659FF21F85DB; Tue, 26 Mar 2013 16:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5lD7EV9K4RH; Tue, 26 Mar 2013 16:45:31 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id E0B5021F8B26; Tue, 26 Mar 2013 16:45:27 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2QNjEZH002900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Mar 2013 19:45:22 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 26 Mar 2013 19:45:07 -0400 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2QNj5Ns022062; Tue, 26 Mar 2013 19:45:06 -0400 Received: from mx15a.corp.emc.com ([169.254.1.81]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Tue, 26 Mar 2013 19:45:05 -0400 From: "Black, David" To: Ted Lemon Date: Tue, 26 Mar 2013 19:45:04 -0400 Thread-Topic: Gen-ART review of draft-ietf-savi-threat-scope-06 Thread-Index: AcwRKxLMGPOwf18pRUizv8st+VLKC4QxHuTAABCsJwAAH6EicA== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71293D36520@MX15A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71293AEEDC8@MX15A.corp.emc.com> <8D23D4052ABE7A4490E77B1A012B63077511F644@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077511F644@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "McPherson, Danny" , "savi@ietf.org" , "ietf@ietf.org" , "gen-art@ietf.org" , Jean-Michel Combes , "joel.halpern@ericsson.com" Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 23:45:32 -0000 Ted, > Remembering that this is an informational draft, which does a pretty good= job > of informing the reader about the problem space, is it your opinion that = the > issues you have raised _must_ be addressed before the document is publish= ed, > or do you think the document is still valuable even if no further text is > added to address your concern? At a minimum, in section 4.1.2, this should be addressed: b) the new text implies that LACP is the only way to cause this situation -= it's not, so LACP should be used as an example. I'm not sure I've seen Fred's response, but that change would suffice. An = RFC Editor note should suffice. Thanks, --David > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Monday, March 25, 2013 9:38 PM > To: Black, David > Cc: McPherson, Danny; Fred Baker; joel.halpern@ericsson.com; gen-art@ietf= .org; > Jean-Michel Combes; savi@ietf.org; ietf@ietf.org > Subject: Re: Gen-ART review of draft-ietf-savi-threat-scope-06 >=20 > On Mar 25, 2013, at 9:04 PM, "Black, David" wrote: > > Summary: This draft is on the right track, but has open issues, describ= ed in > the review. >=20 > While I identified the same issue you did with switching systems that do = link > aggregation and other magic, I think that the document is useful whether = this > is fixed or not. It's true that it doesn't have a full section that talk= s > specifically about this problem, but I think it's unlikely that the autho= rs > are going to add one-when I mentioned it to Joel, he didn't express excit= ement > at the prospect. >=20 > I think Fred's response, while a little salty, accurately represents the > situation: the working group produced this document, the document does wh= at > it's supposed to do, one could continue to polish it indefinitely, but th= en > the document would never get published. >=20 > Remembering that this is an informational draft, which does a pretty good= job > of informing the reader about the problem space, is it your opinion that = the > issues you have raised _must_ be addressed before the document is publish= ed, > or do you think the document is still valuable even if no further text is > added to address your concern? >=20 From joel.halpern@ericsson.com Tue Mar 26 17:16:10 2013 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5AC21F8B0C; Tue, 26 Mar 2013 17:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYYCEV2XRBzV; Tue, 26 Mar 2013 17:16:09 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBD421F8ABA; Tue, 26 Mar 2013 17:16:08 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-35-51523a47fd8b Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 97.D8.02411.74A32515; Wed, 27 Mar 2013 01:16:07 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.004; Tue, 26 Mar 2013 20:16:06 -0400 From: Joel Halpern To: "Ted.Lemon@nominum.com" , "david.black@emc.com" Thread-Topic: Gen-ART review of draft-ietf-savi-threat-scope-06 Thread-Index: AcwRKxLMGPOwf18pRUizv8st+VLKC4QxHuTAABCsJwAAH6EicAABIxTu Date: Wed, 27 Mar 2013 00:16:05 +0000 Message-ID: <6BCE198E4EAEFC4CAB45D75826EFB0760C3313@eusaamb101.ericsson.se> References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71293AEEDC8@MX15A.corp.emc.com> <8D23D4052ABE7A4490E77B1A012B63077511F644@mbx-01.win.nominum.com>, <8D3D17ACE214DC429325B2B98F3AE71293D36520@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71293D36520@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6BCE198E4EAEFC4CAB45D75826EFB0760C3313eusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZXLonUNfdKijQYMZffYuth9eyW7z70s5k 8X7dGTaLq68+s1g82zifxWJK60k2i5u/t7JYbO2OdeDwmPJ7I6vHkSOzWTx2zrrL7rFkyU8m j9cH5rN67NrcwBbAFsVlk5Kak1mWWqRvl8CV8flDO1vBJJuKl0uXMjUwdhp1MXJySAiYSGzd sZsdwhaTuHBvPVsXIxeHkMARRolz6ycwQTjLGSWWfFzFBlLFJqAnsfb9YyYQW0QgSWLWzjss IEXMAm1MEgtvN4MVCQvYSRyYfIwVoshe4vWJR4wQtpvE4RUnWUBsFgFVib5tP8HivALeElcv NUBt62WSOLe7hRkkwSngJXG6/SHYUEag+76fWgO2mVlAXOLWk/lMEHcLSCzZc54ZwhaVePn4 H9BiDqCafInPN0Qg5gtKnJz5hGUCo8gsJN2zEKpmIamCKNGRWLD7ExuErS2xbOFrZhj7zIHH TMjiCxjZVzFylBanluWmGxluYgRG6DEJNscdjAs+WR5ilOZgURLnDXW9ECAkkJ5YkpqdmlqQ WhRfVJqTWnyIkYmDU6qBUUI5IT6j6rPU2Zb3KdU67Iz6lSfd84+3rrt4+chbDscVenwd60yb P96y/+O/l4Wh6Ufkwk72HbURDYm5NWc0rupw7KvZPb0td/F3z2fb76QsEml9MXPuBpW9vHM2 2Z1qVjKYXxeb1XP08URH3Xk/QrMeZn44kRY0sUz4h65idPMbhTPV91n8lViKMxINtZiLihMB /UMDI54CAAA= Cc: "dmcpherson@verisign.com" , "savi@ietf.org" , "ietf@ietf.org" , "gen-art@ietf.org" , "jeanmichel.combes@gmail.com" Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 00:16:10 -0000 --_000_6BCE198E4EAEFC4CAB45D75826EFB0760C3313eusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think I can add text to address this. I will look more closely tomorrow, = and send you a proposal. Thank you for all your efforts reviewing this. Yours, Joel Sent from my Android phone using TouchDown (www.nitrodesk.com) -----Original Message----- From: Black, David [david.black@emc.com] Received: Tuesday, 26 Mar 2013, 7:45pm To: Ted Lemon [Ted.Lemon@nominum.com] CC: McPherson, Danny [dmcpherson@verisign.com]; Fred Baker [fred@cisco.com]= ; Joel Halpern [joel.halpern@ericsson.com]; gen-art@ietf.org [gen-art@ietf.= org]; Jean-Michel Combes [jeanmichel.combes@gmail.com]; savi@ietf.org [savi= @ietf.org]; ietf@ietf.org [ietf@ietf.org] Subject: RE: Gen-ART review of draft-ietf-savi-threat-scope-06 Ted, > Remembering that this is an informational draft, which does a pretty good= job > of informing the reader about the problem space, is it your opinion that = the > issues you have raised _must_ be addressed before the document is publish= ed, > or do you think the document is still valuable even if no further text is > added to address your concern? At a minimum, in section 4.1.2, this should be addressed: b) the new text implies that LACP is the only way to cause this situation -= it's not, so LACP should be used as an example. I'm not sure I've seen Fred's response, but that change would suffice. An = RFC Editor note should suffice. Thanks, --David > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Monday, March 25, 2013 9:38 PM > To: Black, David > Cc: McPherson, Danny; Fred Baker; joel.halpern@ericsson.com; gen-art@ietf= .org; > Jean-Michel Combes; savi@ietf.org; ietf@ietf.org > Subject: Re: Gen-ART review of draft-ietf-savi-threat-scope-06 > > On Mar 25, 2013, at 9:04 PM, "Black, David" wrote: > > Summary: This draft is on the right track, but has open issues, describ= ed in > the review. > > While I identified the same issue you did with switching systems that do = link > aggregation and other magic, I think that the document is useful whether = this > is fixed or not. It's true that it doesn't have a full section that talk= s > specifically about this problem, but I think it's unlikely that the autho= rs > are going to add one-when I mentioned it to Joel, he didn't express excit= ement > at the prospect. > > I think Fred's response, while a little salty, accurately represents the > situation: the working group produced this document, the document does wh= at > it's supposed to do, one could continue to polish it indefinitely, but th= en > the document would never get published. > > Remembering that this is an informational draft, which does a pretty good= job > of informing the reader about the problem space, is it your opinion that = the > issues you have raised _must_ be addressed before the document is publish= ed, > or do you think the document is still valuable even if no further text is > added to address your concern? > --_000_6BCE198E4EAEFC4CAB45D75826EFB0760C3313eusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I think I can add text to address this. I will look more c= losely tomorrow, and send you a proposal.
Thank you for all your efforts reviewing this.

Yours,
Joel

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Black, David [david.black@emc.com]
Received: Tuesday, 26 Mar 2013, 7:45pm
To: Ted Lemon [Ted.Lemon@nominum.com]
CC: McPherson, Danny [dmcpherson@verisign.com]; Fred Baker [fred@cis= co.com]; Joel Halpern [joel.halpern@ericsson.com]; gen-art@ietf.org [gen-ar= t@ietf.org]; Jean-Michel Combes [jeanmichel.combes@gmail.com]; savi@ietf.or= g [savi@ietf.org]; ietf@ietf.org [ietf@ietf.org]
Subject: RE: Gen-ART review of draft-ietf-savi-threat-scope-06

Ted,

> Remembering that this is an informational draft, which does a pretty g= ood job
> of informing the reader about the problem space, is it your opinion th= at the
> issues you have raised _must_ be addressed before the document is publ= ished,
> or do you think the document is still valuable even if no further text= is
> added to address your concern?

At a minimum, in section 4.1.2, this should be addressed:

b) the new text implies that LACP is the only way to cause this situation -= it's
        not, so LACP should be used as a= n example.

I'm not sure I've seen Fred's response, but that change would suffice. = ; An RFC
Editor note should suffice.

Thanks,
--David

> -----Original Message-----
> From: Ted Lemon [mailto:Ted.L= emon@nominum.com]
> Sent: Monday, March 25, 2013 9:38 PM
> To: Black, David
> Cc: McPherson, Danny; Fred Baker; joel.halpern@ericsson.com; gen-art@i= etf.org;
> Jean-Michel Combes; savi@ietf.org; ietf@ietf.org
> Subject: Re: Gen-ART review of draft-ietf-savi-threat-scope-06
>
> On Mar 25, 2013, at 9:04 PM, "Black, David" <david.black@= emc.com> wrote:
> > Summary: This draft is on the right track, but has open issues, d= escribed in
> the review.
>
> While I identified the same issue you did with switching systems that = do link
> aggregation and other magic, I think that the document is useful wheth= er this
> is fixed or not.  It's true that it doesn't have a full section t= hat talks
> specifically about this problem, but I think it's unlikely that the au= thors
> are going to add one-when I mentioned it to Joel, he didn't express ex= citement
> at the prospect.
>
> I think Fred's response, while a little salty, accurately represents t= he
> situation: the working group produced this document, the document does= what
> it's supposed to do, one could continue to polish it indefinitely, but= then
> the document would never get published.
>
> Remembering that this is an informational draft, which does a pretty g= ood job
> of informing the reader about the problem space, is it your opinion th= at the
> issues you have raised _must_ be addressed before the document is publ= ished,
> or do you think the document is still valuable even if no further text= is
> added to address your concern?
>

--_000_6BCE198E4EAEFC4CAB45D75826EFB0760C3313eusaamb101ericsso_-- From jmh@joelhalpern.com Wed Mar 27 09:30:54 2013 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9351421F8B9B; Wed, 27 Mar 2013 09:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL8nmjw6Sp1x; Wed, 27 Mar 2013 09:30:54 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFE321F91B6; Wed, 27 Mar 2013 09:30:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 241A21C08A9; Wed, 27 Mar 2013 09:30:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-233.clppva.east.verizon.net [70.106.135.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 8858A1CA7F1; Wed, 27 Mar 2013 09:30:42 -0700 (PDT) Message-ID: <51531EA4.4030504@joelhalpern.com> Date: Wed, 27 Mar 2013 12:30:28 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Black, David" References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71293AEEDC8@MX15A.corp.emc.com> <8D23D4052ABE7A4490E77B1A012B63077511F644@mbx-01.win.nominum.com> <8D3D17ACE214DC429325B2B98F3AE71293D36520@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71293D36520@MX15A.corp.emc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "McPherson, Danny" , "savi@ietf.org" , "ietf@ietf.org" , "gen-art@ietf.org" , Jean-Michel Combes , Ted Lemon , "joel.halpern@ericsson.com" Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 16:30:55 -0000 Would it suffice to replace 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. ? Proposed changes on the second - fourth lines above. Yours, Joel On 3/26/2013 7:45 PM, Black, David wrote: > Ted, > >> Remembering that this is an informational draft, which does a pretty good job >> of informing the reader about the problem space, is it your opinion that the >> issues you have raised _must_ be addressed before the document is published, >> or do you think the document is still valuable even if no further text is >> added to address your concern? > > At a minimum, in section 4.1.2, this should be addressed: > > b) the new text implies that LACP is the only way to cause this situation - it's > not, so LACP should be used as an example. > > I'm not sure I've seen Fred's response, but that change would suffice. An RFC > Editor note should suffice. > > Thanks, > --David > >> -----Original Message----- >> From: Ted Lemon [mailto:Ted.Lemon@nominum.com] >> Sent: Monday, March 25, 2013 9:38 PM >> To: Black, David >> Cc: McPherson, Danny; Fred Baker; joel.halpern@ericsson.com; gen-art@ietf.org; >> Jean-Michel Combes; savi@ietf.org; ietf@ietf.org >> Subject: Re: Gen-ART review of draft-ietf-savi-threat-scope-06 >> >> On Mar 25, 2013, at 9:04 PM, "Black, David" wrote: >>> Summary: This draft is on the right track, but has open issues, described in >> the review. >> >> While I identified the same issue you did with switching systems that do link >> aggregation and other magic, I think that the document is useful whether this >> is fixed or not. It's true that it doesn't have a full section that talks >> specifically about this problem, but I think it's unlikely that the authors >> are going to add one-when I mentioned it to Joel, he didn't express excitement >> at the prospect. >> >> I think Fred's response, while a little salty, accurately represents the >> situation: the working group produced this document, the document does what >> it's supposed to do, one could continue to polish it indefinitely, but then >> the document would never get published. >> >> Remembering that this is an informational draft, which does a pretty good job >> of informing the reader about the problem space, is it your opinion that the >> issues you have raised _must_ be addressed before the document is published, >> or do you think the document is still valuable even if no further text is >> added to address your concern? >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From david.black@emc.com Wed Mar 27 09:46:05 2013 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A8521F8653; Wed, 27 Mar 2013 09:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTtrlW6Qml5p; Wed, 27 Mar 2013 09:46:04 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 194C121F8689; Wed, 27 Mar 2013 09:43:00 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2RGgub6020378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Mar 2013 12:42:56 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Wed, 27 Mar 2013 12:42:42 -0400 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2RGgfeG022028; Wed, 27 Mar 2013 12:42:41 -0400 Received: from mx15a.corp.emc.com ([169.254.1.81]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Wed, 27 Mar 2013 12:42:41 -0400 From: "Black, David" To: "Joel M. Halpern" Date: Wed, 27 Mar 2013 12:42:40 -0400 Thread-Topic: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 Thread-Index: Ac4rCIJehN22+Ou4SX+dpzVMnYXE+QAAY7Nw Message-ID: <8D3D17ACE214DC429325B2B98F3AE71293D366C6@MX15A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71293AEEDC8@MX15A.corp.emc.com> <8D23D4052ABE7A4490E77B1A012B63077511F644@mbx-01.win.nominum.com> <8D3D17ACE214DC429325B2B98F3AE71293D36520@MX15A.corp.emc.com> <51531EA4.4030504@joelhalpern.com> In-Reply-To: <51531EA4.4030504@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "McPherson, Danny" , "savi@ietf.org" , "ietf@ietf.org" , "gen-art@ietf.org" , Jean-Michel Combes , Ted Lemon , "joel.halpern@ericsson.com" , "Black, David" Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 16:46:05 -0000 That would do nicely. Thanks, --David > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, March 27, 2013 12:30 PM > To: Black, David > Cc: Ted Lemon; McPherson, Danny; savi@ietf.org; ietf@ietf.org; gen- > art@ietf.org; Jean-Michel Combes; joel.halpern@ericsson.com > Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 >=20 > Would it suffice to replace > 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. > ? >=20 > Proposed changes on the second - fourth lines above. > Yours, > Joel >=20 > On 3/26/2013 7:45 PM, Black, David wrote: > > Ted, > > > >> Remembering that this is an informational draft, which does a pretty g= ood > job > >> of informing the reader about the problem space, is it your opinion th= at > the > >> issues you have raised _must_ be addressed before the document is > published, > >> or do you think the document is still valuable even if no further text= is > >> added to address your concern? > > > > At a minimum, in section 4.1.2, this should be addressed: > > > > b) the new text implies that LACP is the only way to cause this situati= on - > it's > > not, so LACP should be used as an example. > > > > I'm not sure I've seen Fred's response, but that change would suffice. = An > RFC > > Editor note should suffice. > > > > Thanks, > > --David > > > >> -----Original Message----- > >> From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > >> Sent: Monday, March 25, 2013 9:38 PM > >> To: Black, David > >> Cc: McPherson, Danny; Fred Baker; joel.halpern@ericsson.com; gen- > art@ietf.org; > >> Jean-Michel Combes; savi@ietf.org; ietf@ietf.org > >> Subject: Re: Gen-ART review of draft-ietf-savi-threat-scope-06 > >> > >> On Mar 25, 2013, at 9:04 PM, "Black, David" wrot= e: > >>> Summary: This draft is on the right track, but has open issues, descr= ibed > in > >> the review. > >> > >> While I identified the same issue you did with switching systems that = do > link > >> aggregation and other magic, I think that the document is useful wheth= er > this > >> is fixed or not. It's true that it doesn't have a full section that t= alks > >> specifically about this problem, but I think it's unlikely that the au= thors > >> are going to add one-when I mentioned it to Joel, he didn't express > excitement > >> at the prospect. > >> > >> I think Fred's response, while a little salty, accurately represents t= he > >> situation: the working group produced this document, the document does= what > >> it's supposed to do, one could continue to polish it indefinitely, but= then > >> the document would never get published. > >> > >> Remembering that this is an informational draft, which does a pretty g= ood > job > >> of informing the reader about the problem space, is it your opinion th= at > the > >> issues you have raised _must_ be addressed before the document is > published, > >> or do you think the document is still valuable even if no further text= is > >> added to address your concern? > >> > > > > _______________________________________________ > > savi mailing list > > savi@ietf.org > > https://www.ietf.org/mailman/listinfo/savi > > From Ted.Lemon@nominum.com Wed Mar 27 19:56:31 2013 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B48E21F9405; Wed, 27 Mar 2013 19:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrN-sQPeDOvZ; Wed, 27 Mar 2013 19:56:31 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id DF02621F9338; Wed, 27 Mar 2013 19:56:30 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUVOxXuiKxhU0/+OkQjNnWx4cfyKuWKGU@postini.com; Wed, 27 Mar 2013 19:56:31 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6FD281B806D; Wed, 27 Mar 2013 19:56:30 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 630AF19005C; Wed, 27 Mar 2013 19:56:30 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Wed, 27 Mar 2013 19:56:30 -0700 From: Ted Lemon To: Joel Halpern Direct Thread-Topic: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 Thread-Index: AcwRKxLMGPOwf18pRUizv8st+VLKC4QxHuTAABCsJwAAH6EicAAx1aQAAABtEwAAABnuAAAVVp6A Date: Thu, 28 Mar 2013 02:56:30 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751243D6@mbx-01.win.nominum.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71293AEEDC8@MX15A.corp.emc.com> <8D23D4052ABE7A4490E77B1A012B63077511F644@mbx-01.win.nominum.com> <8D3D17ACE214DC429325B2B98F3AE71293D36520@MX15A.corp.emc.com> <51531EA4.4030504@joelhalpern.com> <8D3D17ACE214DC429325B2B98F3AE71293D366C6@MX15A.corp.emc.com> <5153222E.30202@joelhalpern.com> In-Reply-To: <5153222E.30202@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8E748BCAD4CEE841BC629F819DE72049@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "McPherson, Danny" , "savi@ietf.org" , "ietf@ietf.org" , "gen-art@ietf.org" , Jean-Michel Combes , "joel.halpern@ericsson.com" , "Black, David" Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 02:56:31 -0000 On Mar 27, 2013, at 12:45 PM, Joel Halpern Direct wrote: > Then it will be done. I will wait for the AD to decide what other change= s 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 secon= d-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 willi= ng to also accommodate David's other request (see below) by adding some tex= t 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 con= cerns. I guess that's ok, but I would have liked to see some text pointin= g out that a MAC move can be detected by the switches and used to update SA= VI 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 addition= al work. From joel.halpern@ericsson.com Wed Mar 27 20:04:13 2013 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6461721F941D; Wed, 27 Mar 2013 20:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bIi38BJhxaF; Wed, 27 Mar 2013 20:04:12 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 009CB21F85BF; Wed, 27 Mar 2013 20:04:11 -0700 (PDT) X-AuditID: c618062d-b7f0d6d00000097e-94-5153b32b381a Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id D8.56.02430.B23B3515; Thu, 28 Mar 2013 04:04:11 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0318.004; Wed, 27 Mar 2013 23:04:10 -0400 From: Joel Halpern To: Ted Lemon Thread-Topic: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 Thread-Index: AcwRKxLMGPOwf18pRUizv8st+VLKC4QxHuTAABCsJwAAH6EicAArjFAAAABtFAAAABnuAAAVVisAAAgnlqA= Date: Thu, 28 Mar 2013 03:04:09 +0000 Message-ID: <6BCE198E4EAEFC4CAB45D75826EFB0760C4AF5@eusaamb101.ericsson.se> References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71293AEEDC8@MX15A.corp.emc.com> <8D23D4052ABE7A4490E77B1A012B63077511F644@mbx-01.win.nominum.com> <8D3D17ACE214DC429325B2B98F3AE71293D36520@MX15A.corp.emc.com> <51531EA4.4030504@joelhalpern.com> <8D3D17ACE214DC429325B2B98F3AE71293D366C6@MX15A.corp.emc.com> <5153222E.30202@joelhalpern.com> <8D23D4052ABE7A4490E77B1A012B6307751243D6@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751243D6@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyuXSPn6725uBAgzu/1Sy2Hl7LbvHuSzuT xdVXn1ksnm2cz2IxpfUkm8XHU2+YLG7+3spisbU71oHD48iR2SweO2fdZfdYsuQnk8e5Kd8Z PV4fmM/qsWtzA1sAWxSXTUpqTmZZapG+XQJXxsSrH9gLJotUTGudy9zA+I6/i5GTQ0LAROJv 52xGCFtM4sK99WxdjFwcQgJHGCX+939gA0kICSxnlPhynwvEZhPQk1j7/jETiC0ioCrx4+Qn FpAGZoFFTBLXt88BaxAWcJXY8eQEG0SRm8TRrkZ2CDtJYvGd62BxFqDm2V9+AQ3i4OAV8JaY 3C4Esfg2s8TL1qXMIDWcAn4ST/7cB6tnBLru+6k1YIuZBcQlbj2ZzwRxtYDEkj3nmSFsUYmX j/+xQtjKEkue7GeBqNeRWLD7ExuErS2xbOFrsHpeAUGJkzOfsExgFJuFZOwsJC2zkLTMQtKy gJFlFSNHaXFqWW66kcEmRmAkHpNg093BuOel5SFGaQ4WJXHeINcLAUIC6YklqdmpqQWpRfFF pTmpxYcYmTg4pRoYgxR3W9xqjl5bsO5J7OdvrXbW9+/LH82T/Cjy3J2zdPv1EmOWmdVW52+s CeMtkn/sffntn0L70zeLeMLe+j999potyD2cSY5/95lghw1ntVZH1J9NsBObXSXIuuwR9yV5 2df+19e+/hx0ofi45bbOrtqWey+/T9W8cOf8XI351UzrAl7kK/lvV2Ipzkg01GIuKk4EAOwS eKGSAgAA Cc: "McPherson, Danny" , "savi@ietf.org" , "ietf@ietf.org" , "gen-art@ietf.org" , Jean-Michel Combes , "Black, David" Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 03:04:13 -0000 I will try to come up with a way to address the MAC move topic. The challe= nge is to word it in such a way that it does not imply a new protocol for c= ommunicating such a move (Savi was/is prohibited by charter from doing prot= ocol development.) Yours, Joel > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 > Sent: Wednesday, March 27, 2013 10:57 PM > To: Joel Halpern Direct > Cc: Black, David; Joel M. Halpern; McPherson, Danny;=20 > savi@ietf.org; ietf@ietf.org; gen-art@ietf.org; Jean-Michel=20 > Combes; Joel Halpern > Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 >=20 > On Mar 27, 2013, at 12:45 PM, Joel Halpern Direct=20 > wrote: >=20 > > Then it will be done. I will wait for the AD to decide=20 > what other changes are needed, and then will either make this=20 > change or include it in an RFC Editor note. >=20 > > 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. >=20 > I think you probably meant "or", not "are", in the second=20 > word of the second-to-last line of the new text. >=20 > As far as I am concerned, given that David is happy with your=20 > recent change, I'm happy with it too. However, since you=20 > are asking, if you were willing to also accommodate David's=20 > other request (see below) by adding some text to the document=20 > in section 5, that would be an added bonus: >=20 > > A paragraph has been added to 5.2.3 to address all three of=20 > the above concerns. I guess that's ok, but I would have=20 > liked to see some text pointing out that a MAC move can be=20 > detected by the switches and used to update SAVI state about=20 > which port(s) a MAC is accessed through. >=20 > So if you can do this, it would be much appreciated; if you=20 > can't do it, I think the document is valuable enough to move=20 > forward without this additional work. >=20 > = From jmh@joelhalpern.com Fri Mar 29 15:08:01 2013 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA5B21F901A; Fri, 29 Mar 2013 15:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1sQQJw-ySQz; Fri, 29 Mar 2013 15:08:01 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 070B521F901F; Fri, 29 Mar 2013 15:07:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id DBB4F1CCC9C; Fri, 29 Mar 2013 15:07:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-52.clppva.east.verizon.net [70.106.135.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 5761C1C9E48; Fri, 29 Mar 2013 15:07:56 -0700 (PDT) Message-ID: <515610B0.2050204@joelhalpern.com> Date: Fri, 29 Mar 2013 18:07:44 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ted Lemon References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71293AEEDC8@MX15A.corp.emc.com> <8D23D4052ABE7A4490E77B1A012B63077511F644@mbx-01.win.nominum.com> <8D3D17ACE214DC429325B2B98F3AE71293D36520@MX15A.corp.emc.com> <51531EA4.4030504@joelhalpern.com> <8D3D17ACE214DC429325B2B98F3AE71293D366C6@MX15A.corp.emc.com> <5153222E.30202@joelhalpern.com> <8D23D4052ABE7A4490E77B1A012B6307751243D6@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751243D6@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "McPherson, Danny" , "savi@ietf.org" , "ietf@ietf.org" , "gen-art@ietf.org" , Jean-Michel Combes , "joel.halpern@ericsson.com" , "Black, David" Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 22:08:02 -0000 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 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. > > From david.black@emc.com Fri Mar 29 15:59:25 2013 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174C521F8C83; Fri, 29 Mar 2013 15:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81jpheRAwxZY; Fri, 29 Mar 2013 15:59:24 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id ABF3F21F8B61; Fri, 29 Mar 2013 15:59:20 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2TMxGPG020843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Mar 2013 18:59:16 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 29 Mar 2013 18:58:57 -0400 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2TMwuvS027472; Fri, 29 Mar 2013 18:58:57 -0400 Received: from mx15a.corp.emc.com ([169.254.1.81]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Fri, 29 Mar 2013 18:58:56 -0400 From: "Black, David" To: "Joel M. Halpern" , Ted Lemon Date: Fri, 29 Mar 2013 18:58:55 -0400 Thread-Topic: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 Thread-Index: Ac4szVjS9UAHr94bQtuYWuQh61daWAAAsYBA Message-ID: <8D3D17ACE214DC429325B2B98F3AE71293D36C5C@MX15A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71293AEEDC8@MX15A.corp.emc.com> <8D23D4052ABE7A4490E77B1A012B63077511F644@mbx-01.win.nominum.com> <8D3D17ACE214DC429325B2B98F3AE71293D36520@MX15A.corp.emc.com> <51531EA4.4030504@joelhalpern.com> <8D3D17ACE214DC429325B2B98F3AE71293D366C6@MX15A.corp.emc.com> <5153222E.30202@joelhalpern.com> <8D23D4052ABE7A4490E77B1A012B6307751243D6@mbx-01.win.nominum.com> <515610B0.2050204@joelhalpern.com> In-Reply-To: <515610B0.2050204@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "McPherson, Danny" , "savi@ietf.org" , "ietf@ietf.org" , "gen-art@ietf.org" , Jean-Michel Combes , "joel.halpern@ericsson.com" , "Black, David" Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 22:59:25 -0000 Joel, Yes, I think you do have the right end of the question, and that new text l= ooks ok, as the previous sentence introduces the gratuitous ARP. To summarize, we've decided to address two of the three concerns from the r= eview of -06. The third concern that will not be addressed is:=20 > a) the alternative of statically allowing all source addresses through al= l > teamed/aggregated links (decouples SAVI state from link teaming/aggregati= on > state) should also be mentioned, I'm satisfied with this outcome. Thanks, --David > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Friday, March 29, 2013 6:08 PM > To: Ted Lemon > Cc: Black, David; McPherson, Danny; savi@ietf.org; ietf@ietf.org; gen- > art@ietf.org; Jean-Michel Combes; joel.halpern@ericsson.com > Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 >=20 > 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. >=20 > Yours, > Joel >=20 > On 3/27/2013 10:56 PM, Ted Lemon wrote: > > On Mar 27, 2013, at 12:45 PM, Joel Halpern Direct > wrote: > > > >> Then it will be done. I will wait for the AD to decide what other cha= nges > 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 ch= ange, > I'm happy with it too. However, since you are asking, if you were willi= ng 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 additi= onal > work. > > > >