Thats a fair point. So if the definition was more descriptive of the place in 
the network and not of the functionality would that address your concern?

--
Paul Unbehagen


On Jun 19, 2012, at 9:25 AM, "Joel M. Halpern" <[email protected]> wrote:

> 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

Reply via email to