As a clarification, the text which specified "switches/routers" in -01 was the proper text and got lost by mistake in -02. It will be fixed to say "switches/routers" instead of "switches" only.
Marc -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Joel M. Halpern Sent: Tuesday, June 19, 2012 5:25 PM To: Paul Unbehagen Cc: Ivan Pepelnjak; Benson Schliesser; [email protected]; LASSERRE, MARC (MARC) Subject: Re: [nvo3] call for adoption: draft-lasserre-nvo3-framework-02 If you want to make that point, then go back to the text as it was in the previous version. Do not make the point by hiding it in a confusing definition. The ToR devices were not what I was concerned about. I can live with saying they may be routers. I can live with describing them as switches. It was the Intra-DC devices that I was concerned about. Adding marketing confusion to the definitions would create a new issue for me to be concerned about. Yours, Joel On 6/19/2012 11:06 AM, Paul Unbehagen wrote: > Ivan is making a good point that switch's acting as ToR's have routing > capability in them as well. This should be documented as a state of reality. > > -- > Paul Unbehagen > > > On Jun 19, 2012, at 8:14 AM, "Joel M. Halpern" <[email protected]> wrote: > >> Please do not aggravate the mess marketing produced by redefining switch to >> include router. >> >> Yours, >> Joel >> >> >> On 6/19/2012 6:17 AM, Ivan Pepelnjak wrote: >>> It's the classic "what is a SWITCH" confusion caused by some >>> marketing whiz more than a decade ago. I'm not too familiar with >>> what you can or cannot do within an ID/RFC, but the logical thing to >>> do would be to define ... >>> >>> Switch = a network device performing packet forwarding based on L2 >>> or L3 headers, or a combination of both >>> >>> ToR = ToR switch (unless indicated otherwise) >>> >>> ... or something similar in the General Terminology section. >>> >>> Kind regards, >>> >>> Ivan >>> >>> *From:*[email protected] [mailto:[email protected]] *On >>> Behalf Of *LASSERRE, MARC (MARC) >>> *Sent:* Tuesday, June 19, 2012 12:07 PM >>> *To:* Joel M. Halpern; Benson Schliesser >>> *Cc:* [email protected] >>> *Subject:* Re: [nvo3] call for adoption: >>> draft-lasserre-nvo3-framework-02 >>> >>> It was certainly not a deliberate change to imply that L3 was not >>> needed... >>> >>> Could you suggest which sentence(s) need clarification? >>> >>> Thanks, >>> >>> Marc >>> >>> -----Original Message----- >>> From: [email protected] <mailto:[email protected]> >>> [mailto:[email protected]] On Behalf Of Joel M. Halpern >>> Sent: Tuesday, June 19, 2012 1:27 AM >>> To: Benson Schliesser >>> Cc: [email protected] <mailto:[email protected]> >>> Subject: Re: [nvo3] call for adoption: >>> draft-lasserre-nvo3-framework-02 >>> >>> I probably would have sent a private comment, but not bothered the >>> list, >>> >>> if it was just ToR entities. But the document has changed what the >>> ToR >>> >>> entities are connect to from being switches / routers to being switches. >>> >>> It is that change which concerns me, and for which I seek explanation. >>> >>> Yours, >>> >>> Joel >>> >>> PS: I actually agree that the common usage is ToR switch, and the >>> common >>> >>> deployment is to put L2 devices in that place in the topology. >>> >>> On 6/18/2012 7:20 PM, Benson Schliesser wrote: >>> >>>> Hi, Joel. >>> >>>> >>> >>>> I would like for the authors to respond with their own comments. >>>> But >>> speaking only for myself (as an individual): >>> >>>> >>> >>>> I think that common usage of the unqualified term "ToR" generally >>> refers to a "ToR switch". While the term "ToR" literally refers to a >>> location, and could be used to describe a "ToR router" or "ToR >>> storage array" etc, in my experience the definition in the framework >>> draft is fairly accurate. (And moreover, "switch" isn't necessarily >>> limited to L2... forwarding != routing, and encap / tunneling makes >>> this even more >>> confusing.) >>> >>>> >>> >>>> But regardless, I think the definition of "ToR" is more-or-less >>> inconsequential to the framework. We should get it right, of course. >>> But it's more important that we define the NVE correctly. And the >>> NVE could perhaps be resident in many types of device, including a >>> device that is not exactly a router but does have L3 interface(s). >>> >>>> >>> >>>> In the draft, the ToR concept is introduced in an "example of >>> multi-tier DC network architecture". I know from experience that >>> there are many possible variations on where the access and >>> aggregation layers are located. Do you think the authors should make >>> the example more generic, perhaps change ToR to "access" or >>> something like that? It's not clear to me what's best here - suggestions >>> would be appreciated. >>> >>>> >>> >>>> Cheers, >>> >>>> -Benson >>> >>>> >>> >>>> >>> >>>> On Jun 18, 2012, at 5:07 PM, Joel M. Halpern wrote: >>> >>>> >>> >>>>> I sent the comment below to the authors, upon reviewing the diffs >>> from the previous version of this draft. I would appreciate >>> clarification on this issue before the WG adopts this document as a >>> basis for further work: >>> >>>>> >>> >>>>> In looking at the latest revision of this draft, the text seems to >>> have moved from describing the devices at the ToR as switches / >>> routers to refering to them as just switches. I can not tell if >>> this change is because the authors understand switch to include IP >>> forwarding device (possibly with IP routing protocol support), or if >>> there is a change in capabilities envisioned. >>> >>>>> If the former, it should be stated explicitly, since it is an >>> unusual usage. >>> >>>>> If the later, I am confused as the document then very clearly >>>>> states >>> that the data center interconnect devices (now referred to in >>> section >>> 1.3 as switches) are L3 capable devices. In fact, the premise of >>> the document requires such L3 capable devices (usually known as >>> routers.) Thus, teh sentence "Core switches are usually Ethernet >>> switches, but can also support routing capabilities" seems very >>> strange. switches != routers. And this document and the WG charter >>> requires those devices to support L3 capabilities. >>> >>>>> >>> >>>>> Thank you, >>> >>>>> Joel M. Halpern >>> >>>>> >>> >>>>> On 6/18/2012 5:51 PM, Benson Schliesser wrote: >>> >>>>>> Dear NVO3 Participants - >>> >>>>>> >>> >>>>>> This message begins a two week Call for Adoption of >>> http://tools.ietf.org/html/draft-lasserre-nvo3-framework-02 by the >>> NVO3 working group, ending on 02-July-2012. >>> >>>>>> >>> >>>>>> Please respond to the NVO3 mailing list with any statements of >>> approval or disapproval, along with any additional comments that >>> might explain your position. Also, if any NVO3 participant is aware >>> of IPR associated with this draft, please inform the mailing list >>> and/or the >>> NVO3 chairs. >>> >>>>>> >>> >>>>>> Thanks, >>> >>>>>> -Benson & Matthew >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> nvo3 mailing list >>> >>>>>> [email protected] <mailto:[email protected]> >>> >>>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >>>>>> >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> nvo3 mailing list >>> >>>>> [email protected] <mailto:[email protected]> >>> >>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >>>> >>> >>>> >>> >>> _______________________________________________ >>> >>> nvo3 mailing list >>> >>> [email protected] <mailto:[email protected]> >>> >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
