[rbridge] per-VLAN instances of IS-IS
Radia Perlman
Radia.Perlman at sun.com
Wed Jun 20 12:59:56 PDT 2007
I'm also assuming we are doing multipathing, not just of unicast, but
also multicast.
Radia
Anoop Ghanwani wrote:
> Personally, I would like the group to get to a
> consensus on the ECMP issue fairly quickly.
>
> I too, just like Silvano, thought it was going
> to be done.
>
> Anoop
>
>
>> -----Original Message-----
>> From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com]
>> Sent: Wednesday, June 20, 2007 7:29 AM
>> To: Silvano Gai; Anoop Ghanwani
>> Cc: rbridge at postel.org; Radia Perlman
>> Subject: RE: [rbridge] per-VLAN instances of IS-IS
>>
>> Silvano,
>>
>> Yes, that was probably discussed earlier in May.
>>
>> AFAIK, discussion != consensus.
>>
>> Possibly your customers need to explain to you that the
>> difference between "core" and "not core" is not always as
>> clear cut as you apparently think it is. Nor is it
>> necessarily going to be simple for a device to determine
>> which of the available equal cost paths only contain core elements.
>>
>> Also, ECMP - at least in the traditional sense - takes
>> place where equal costs exist in a "routing" domain. That is
>> at least as likely to occur in locii containing one or more
>> edge components, as it is anywhere else.
>>
>> There are certainly limited applications - typically
>> requiring careful configuration to restrict ECMP-like
>> activity to very specifically defined equal cost paths -
>> where it will be possible to say "we do ECMP only in the
>> core." I personally wonder why link-bundling wouldn't be a
>> better solution in those cases, however.
>>
>> Thanks!
>>
>> --
>> Eric Gray
>> Principal Engineer
>> Ericsson
>>
>>
>>> -----Original Message-----
>>> From: Silvano Gai [mailto:sgai at nuovasystems.com]
>>> Sent: Tuesday, June 19, 2007 11:39 PM
>>> To: Eric Gray (LO/EUS); Anoop Ghanwani
>>> Cc: rbridge at postel.org; Radia Perlman
>>> Subject: RE: [rbridge] per-VLAN instances of IS-IS
>>> Importance: High
>>>
>>> We had this discussion on May 8th, 2007 on this mailing list.
>>>
>>> In a nutshell: we do ECMP only in the core, but we don't
>>>
>> learn in the
>>
>>> core, so I don't see the problem.
>>>
>>> -- Silvano
>>>
>>>
>>>> -----Original Message-----
>>>> From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com]
>>>> Sent: Tuesday, June 19, 2007 7:14 AM
>>>> To: Silvano Gai; Anoop Ghanwani
>>>> Cc: rbridge at postel.org; Radia Perlman
>>>> Subject: RE: [rbridge] per-VLAN instances of IS-IS
>>>>
>>>> Silvano,
>>>>
>>>> Your response is confusing. If we are not expected to preserve
>>>> forwarding symmetry, have we given up on presumed
>>>>
>> compatibility with
>>
>>>> standard bridges?
>>>>
>>>> --
>>>> Eric Gray
>>>> Principal Engineer
>>>> Ericsson
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Silvano Gai [mailto:sgai at nuovasystems.com]
>>>>> Sent: Tuesday, June 19, 2007 9:13 AM
>>>>> To: Eric Gray (LO/EUS); Anoop Ghanwani
>>>>> Cc: rbridge at postel.org; Radia Perlman
>>>>> Subject: RE: [rbridge] per-VLAN instances of IS-IS
>>>>> Importance: High
>>>>>
>>>>>
>>>>> Eric,
>>>>>
>>>>> You say: "we're expected to preserve forwarding symmetry".
>>>>>
>>>>> WE ARE NOT.
>>>>>
>>>>> Where does the current draft preserve forwarding symmetry?
>>>>>
>>>>> In regard to your conclusions, many of us (Anoop , Dinesh
>>>>>
>>> and I for
>>>
>>>>> sure) are participating because we are building real products.
>>>>>
>>>>> I don't buy your argument that "Very uninteresting
>>>>> (technology) is very
>>>>> good."
>>>>>
>>>>> -- Silvano
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: rbridge-bounces at postel.org
>>>>>>
>>> [mailto:rbridge-bounces at postel.org]
>>>
>>>>> On
>>>>>
>>>>>> Behalf Of Eric Gray (LO/EUS)
>>>>>> Sent: Tuesday, June 19, 2007 5:27 AM
>>>>>> To: Anoop Ghanwani
>>>>>> Cc: rbridge at postel.org; Radia Perlman
>>>>>> Subject: Re: [rbridge] per-VLAN instances of IS-IS
>>>>>>
>>>>>> Anoop,
>>>>>>
>>>>>> I think we strongly disagree on what it means
>>>>>>
>>> to incorporate
>>>
>>>>>> something in the control protocol. From there, it is
>>>>>>
>>> likely that
>>>
>>>>>> we also disagree on how best to avoid doing so.
>>>>>>
>>>>>> Figuring out how to correctly carry
>>>>>>
>>> IGMP-snooped information
>>>
>>>>>> in TRILL protocol is effectively the same thing as
>>>>>>
>> incorporating
>>
>>>>>> IGMP in the control protocol.
>>>>>>
>>>>>> Making a list of everything that bridges snoop
>>>>>>
>>> and ensuring
>>>
>>>>>> we can also include that information in IS-IS is
>>>>>>
>>> exactly the sort
>>>
>>>>>> of thing we should be trying to avoid. The good news
>>>>>>
>> is that it
>>
>>>>>> also should be easy to avoid.
>>>>>>
>>>>>> Whatever protocols we might use, TRILL is
>>>>>>
>>> essentially a layer
>>>
>>>>>> two forwarding technology. The messages that layer two
>>>>>>
>>> forwarding
>>>
>>>>>> technologies want to snoop are visible to the devices
>>>>>>
>>> involved in
>>>
>>>>>> forwarding. Unless devices actively interfere with
>>>>>>
>>> "normal" layer
>>>
>>>>>> two forwarding, "external" control messages should be
>>>>>>
>>> no different
>>>
>>>>>> than any other form of data - as far as RBridges are
>>>>>>
>> concerned -
>>
>>>>>> and should be forwarded in the same way.
>>>>>>
>>>>>> We know that we're expected to preserve
>>>>>>
>>> forwarding symmetry
>>>
>>>>>> - at least for the layer two encapsulation of TRILL
>>>>>>
>>> frames. In the
>>>
>>>>>> same way, and for similar reasons, we may need to
>>>>>>
>> preserve path
>>
>>>>>> congruency. This is implicit in the decision to
>>>>>>
>> learn from data
>>
>>>>>> in the unicast case.
>>>>>>
>>>>>> What we don't know is the complete list of
>>>>>>
>>> things that depend
>>>
>>>>>> on our doing that. But we can compose a partial list, and it
>>>>>>
>>> seems
>>>
>>>>>> to me that "snooping" (in general) is one example,
>>>>>>
>> OA&M may well
>>
>>> be
>>>
>>>>>> another and there are bound to be more.
>>>>>>
>>>>>> As for the notion of "crippling the technology
>>>>>>
>>> and making it
>>>
>>>>>> very uninteresting" - well, to many people, technology becomes
>>>>>>
>>> very
>>>
>>>>>> interesting when it is very complicated to make it
>>>>>>
>>> work. For the
>>>
>>>>>> users of any technology, it is only truly useful when
>>>>>>
>> it is not
>>
>>> very
>>>
>>>>>> interesting.
>>>>>>
>>>>>> Paraphrasing something a colleague once told
>>>>>>
>>> me: a technology
>>>
>>>>>> is only really useful when the interesting thing in
>>>>>>
>> using it is
>>
>>> not
>>>
>>>>>> about the technology, but about its use. Put another way, you
>>>>>>
>>> know
>>>
>>>>>> that transportation is useful when the interesting thing about
>>>>>>
>>> using
>>>
>>>>>> it is arriving at the destination - rather than the
>>>>>>
>> trip itself.
>>
>>>>>> Uninteresting is good. Very uninteresting is very good.
>>>>>>
>>>>>> --
>>>>>> Eric Gray
>>>>>> Principal Engineer
>>>>>> Ericsson
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Anoop Ghanwani [mailto:anoop at brocade.com]
>>>>>>> Sent: Monday, June 18, 2007 7:08 PM
>>>>>>> To: Eric Gray (LO/EUS)
>>>>>>> Cc: rbridge at postel.org; Radia Perlman
>>>>>>> Subject: RE: [rbridge] per-VLAN instances of IS-IS
>>>>>>> Importance: High
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com]
>>>>>>>> Sent: Monday, June 18, 2007 11:43 AM
>>>>>>>> To: Anoop Ghanwani
>>>>>>>> Cc: rbridge at postel.org; Radia Perlman
>>>>>>>> Subject: RE: [rbridge] per-VLAN instances of IS-IS
>>>>>>>>
>>>>>>>> Anoop,
>>>>>>>>
>>>>>>>> I tend to view your response below as yet
>>>>>>>>
>> another reason
>>
>>>>>>>> why RBridges MUST use a common path for unicast and
>>>>>>>> multicast (as well as broadcast and flooded) traffic. In
>>>>>>>> fact, it is a very good reason to limit use of
>>>>>>>>
>>> "multipathing"
>>>
>>>>>>>> in general.
>>>>>>>>
>>>>>>> If we do place those constraints then it would cripple the
>>>>>>> technology and make it very uninteresting (at least to me).
>>>>>>>
>>>>>>>
>>>>>>>> It is not clear exactly what you mean by your
>>>>>>>>
>> reference to
>>
>>>>>>>> differences between control and data paths. Control
>>>>>>>> messages are from one RBridge to another and -
>>>>>>>>
>> presumably -
>>
>>>>>>>> follow the same path as data addressed from RBridge to
>>>>>>>> RBridge. That path may be different from data
>>>>>>>>
>>> transitting an
>>>
>>>>>>>> RBridge campus, but there is no RBridge "control" traffic
>>>>>>>> that transits a campus.
>>>>>>>>
>>>>>>>> Are you suggesting that IGMP should be treated
>>>>>>>>
>> as a control
>>
>>>>>>>> protocol within TRILL?
>>>>>>>>
>>>>>>> In this case, when I said control I meant IGMP
>>>>>>>
>> (since that is
>>
>>>>>>> what is being used to effect pruning). If we snoop on the
>>>>>>> information at the edge of the trill cloud and pass this
>>>>>>> information around in IS-IS, then we don't need to
>>>>>>>
>> worry about
>>
>>>>>>> treating it as a separate control protocol.
>>>>>>>
>>>>>>>
>>>>>>>> Nor is it very clear why this observation is
>>>>>>>>
>> specific to
>>
>>>>>>>> our discussion of multicast optimization. As a general
>>>>>>>> rule, if there is one reasonably well know
>>>>>>>>
>> application that
>>
>>>>>>>> relies on path congruency for proper operation, there are
>>>>>>>> probably others.
>>>>>>>>
>>>>>>>> Do you think we should provide a logical
>>>>>>>>
>> control-function
>>
>>>>>>>> "bridging" service for all such
>>>>>>>>
>>> applications
>>>
>>>>>>>> as a result of path divergences we introduce? Should we
>>>>>>>> conduct a research project to determine what
>>>>>>>>
>> other "control
>>
>>>>>>>> protocols" we need to include in TRILL?
>>>>>>>>
>>>>>>> We would need to make a list of everything that
>>>>>>>
>> bridges snoop
>>
>>>>>>> on and make sure we have ways of sending that
>>>>>>>
>> around in IS-IS
>>
>>>>>>> (if we care about those functions).
>>>>>>> I'm not aware of anything other than IGMP that trill would
>>>>>>> need to worry about, though.
>>>>>>>
>>>>>>> Anoop
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> rbridge mailing list
>>>>>> rbridge at postel.org
>>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>>>
More information about the rbridge
mailing list