On Thu, Apr 9, 2009 at 7:49 PM, Radia Perlman <
Radia.Perlman at sun.com> wrote:
> Yes, Dinesh, I agree. All we need to do is say that in TRILL Hellos MUST NOT
> be padded.
>
> Radia
>
> Dinesh G Dutt wrote:
>>
>> Radia,
>>
>> I'd like to reiterate that all we ought to really care about is non-padded
>> Hellos. That fixes our problem of creating loops otherwise. Everything else
>> is optional and nice-to-have.
>>
>> David, if we restrict our request to just this, would it be more palatable
>> to the IS-IS WG ?
>>
>> Dinesh
>> Radia Perlman wrote:
>>
>>>
>>> Dave,
>>>
>>> I think a lot of the controversy is due to overloaded terminology, and
>>> using words that people have preconceived notions for.
>>> One term that seems to be confusing people is the term "Forming
>>> adjacency".
>>>
>>> "Forming adjacency" is a term that implies a bunch of steps to
>>> layer 3 IS-IS people that the TRILL people (including me) are
>>> not implying all the steps of.
>>> So it's possible that TRILL people should not use the term "forming
>>> adjacency"
>>> in emails describing protocols, or perhaps the layer 3 IS-IS people could
>>> try not to read too much into that phrase and instead just follow through
>>> all the described steps in the
>>> protocol being proposed.
>>>
>>> "Designated DRB" is two functions in TRILL, where it's only the second
>>> function in layer 3 IS-IS:
>>>
>>> a) the one that serves specific TRILL purposes: deciding who should be
>>> the Designated Forwarder for each VLAN
>>> so there are no loops, deciding on Designated VLAN for inter-RBridge
>>> communication, etc.
>>> b) the IS-IS specific stuff: naming the pseudonode, sending CSNPs
>>>
>>> In TRILL it is *essential* to get the first thing robust, i.e., never
>>> having multiple forwarders. In layer 3 IS-IS, it's
>>> OK to have multiple DRs. In TRILL it is *fatal*.
>>> So the first thing TRILL has to do is to get that right. The solution,
>>> fortunately, is easy :
>>>
>>> . Unpadded Hellos.
>>> . Choosing DRB regardless of 2-way connectivity, MTU, etc.
>>>
>>> This is (and *must* be) different from the way layer 3 IS-IS happens to
>>> work.
>>> Regardless of philosophical discussions that we could carry on forever
>>> about whether this makes TRILL a
>>> different protocol, different version of the protocol, whatever....it is
>>> clear that is what TRILL needs to do.
>>> I have no objection to no longer calling the TRILL routing protocol
>>> "IS-IS" if that is considered "too big
>>> a change" from layer 3 IS-IS. But we have to do the obvious correct
>>> technical thing for TRILL.
>>>
>>> The other thing that seems to be confusing people is the term "Hello
>>> protocol".
>>> The Hellos in layer 3 IS-IS have two purposes:
>>> a) checking MTU size
>>> b) finding neighbors, choosing DR
>>>
>>> TRILL is just separating the two functions (choosing DRB, and testing MTU
>>> size), and calling it
>>> two different protocols; the "Hello" and the "MTU probe protocol". Layer
>>> 3 people could just think of
>>> it as a terminology change. It seems cleaner to call it two different
>>> protocols, since they are
>>> serving two very different functions. Having one protoocol that does
>>> both, the way it is today
>>> in layer 3 IS-IS, DOES NOT WORK FOR TRILL. And it's much simpler to think
>>> about
>>> the two problems individually, and make sure we get them both right. If
>>> you like, we can
>>> call the MTU probe protocol "padded Hellos", but let's first make sure we
>>> are getting
>>> both protocols correct. Even if we call the MTU probe protocol "padded
>>> Hellos", the
>>> padded Hello protocol MUST NOT have any influence on the "choosing a
>>> Designated
>>> DRB" (the thingy in TRILL that ensures there is only a single Designated
>>> Forwarder
>>> per VLAN on the link).
>>>
>>> The technical issues (ignoring terminology) that are being discussed for
>>> variants of the "MTU probe
>>> protocol" are:
>>> a) whether to ignore MTU probing entirely, because it's simpler to
>>> just ignore it, and just ensure that
>>> there is only one DRB on the link: and live with occasionally LSPs,
>>> CSNPs, data packets, not
>>> getting through on some link (which in TRILL is FAR less serious than
>>> having multiple forwarders)
>>> b) whether to make MTU probing just test that the link meets the criteria
>>> of the permanent
>>> fixed minimum size of 1450, or whatever, or whether to allow campuses to
>>> have a different
>>> campus-wide minimum link size S, and have RBridges test that their links
>>> can handle size "S"
>>> in the probing protocol, rather than "1450". Regardless of what the size
>>> is, and how that
>>> size is determined, it's clear what should happen if a link doesn't meet
>>> size S. The link
>>> should not be considered part of the topology -- routes should not be
>>> computed that
>>> traverse such a link.
>>>
>>> Radia
>>>
>>>
>>>
>>>
>>>
>>>
>>> David Ward wrote:
>>>
>>>>
>>>> All -
>>>>
>>>> This discussion is rapidly defining !IS-IS as a solution given the
>>>> changes to the protocol. At least enough of the protocol is being changed
>>>> that we need to consider a new version designator as the direction is
>>>> fundamentally changing adj formation, DIS election, LSP size, etc and
>>>> compatibility with current ISIS doesn't seem a goal. I'd like to push the
>>>> brakes just a bit to try and get us into better sync.
>>>>
>>>> There are proposals that the Hellos should NOT be padded to eliminate a
>>>> cause of multiple rbridges on the same LAN "not seeing each other" and
>>>> electing multiple forwarders. However, the idea in the discussion is to
>>>> remove the required MTU checking and it is proposed (which I don't
>>>> understand) to introduce another "MTU discovery" protocol to restore this
>>>> awareness.
>>>>
>>>> As we know, IS-IS requires that the DIS is elected from among the
>>>> routers that have adjacencies (that report the existence of each other in
>>>> the IIHs, and it requires that the IIHs are padded to the maximum of the
>>>> link MTU and the originating L1LSPBufferSize - in the case of L1). This
>>>> ensures both that the link is capable of transferring data packets of link
>>>> MTU size, and more that it is capable of transferring LSPs of the
>>>> appropriate network wide size. If this were not the case, then it is
>>>> possible that a DIS could get elected which was not capable of operating the
>>>> reliable update process, and could cause certain LSPs to fail to be
>>>> propagated across the LAN.
>>>>
>>>> The DRB is the TRILL equivalent of the DIS. This is elected from among
>>>> the routers connected to the LAN and is responsible for:
>>>> a) generating a pseudonode LSP, which claims connectivity to all
>>>> the other routers it sees on the LAN. (and in the OSI case reports the ESs
>>>> on the LAN)
>>>> b) running the LAN reliable update process (i.e. periodically
>>>> sending CSNPs etc)
>>>>
>>>> So the padding is required in order to ensure that IS-IS operates
>>>> correctly. The problem is that the roll of the DIS (aka DRB) is defined in
>>>> terms of adjacency formation, and I don't understand how the two distinct
>>>> roles for the DRB can be combined into a single DRB. Again, I've followed
>>>> and read the TRILL and ISIS but, I am not seeing a way to combine the
>>>> functions into a single DIS/DRB at this point.
>>>>
>>>> My view (which others have stated earlier) is that the L2ISIS desired
>>>> functionality should not mess with the existing IS-IS DIS election
>>>> mechanisms, but should have another set of "hellos" which can be used for
>>>> the TRILL specific DRB elections, and have the appropriate rules for that.
>>>> Or, we at least need to write down the rules and explore how to combine
>>>> them.
>>>>
>>>> There appears only one way out of this:
>>>>
>>>> - TRILL WG should write down the specific requirements and functionality
>>>> are and what the "rules" should be for them. We may find ISIS is suited to
>>>> meet them or not.
>>>>
>>>> Thanks
>>>>
>>>> -DWard
>>>>
>>>> Note that if the requirement is that TRILL needs to operate in
>>>> environments with different or "variable" (though static) MTUs, we should
>>>> not hack an easy solution but, create a generalized solution
>>>>
>>>> On Apr 7, 2009, at 3:10 PM, Radia Perlman wrote:
>>>>
>>>>
>>>>>
>>>>> OK. It's clear we should NOT pad Hellos.
>>>>>
>>>>> It also seems like enough people would feel uncomfortable with not
>>>>> doing MTU discovery that we should make
>>>>> sure there is a mechanism for that also.
>>>>>
>>>>> So can we focus for a minute on the following question, "whether to
>>>>> make MTU size a forever constant,
>>>>> or configurable in a campus", as described below.
>>>>>
>>>>> The simplest option is to pick some minimum size, say 1450 bytes, put
>>>>> that in the spec now, and forever
>>>>> say that TRILL Hellos and LSPs cannot be bigger than that.
>>>>> MTU discovery would be done to ensure that
>>>>> every link can handle 1450 bytes, and not use (not report in LSPs)
>>>>> links that can't handle that.
>>>>>
>>>>> However, my preference is to have an optional TLV in the LSP that says
>>>>> "campus-wide MTU size". This TLV
>>>>> would only be relevant if:
>>>>> a) it is larger than 1450, and
>>>>> b) it is in the LSP of the highest priority RBridge in the campus.
>>>>>
>>>>> If we put that in, then we would be enabling TRILL campuses that
>>>>> support jumbo frames.
>>>>>
>>>>> The rule is that if the highest priority RBridge says MTU size should
>>>>> be 10000 bytes, then all RBridges would adjust
>>>>> their buffer sizes, and test their adjacencies to ensure they could
>>>>> handle 10000 bytes, and if they don't
>>>>> then stop reporting those links (just like they would with the simpler
>>>>> proposal if the links
>>>>> couldn't support 1450).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Isis-wg mailing list
>>>>>
Isis-wg at ietf.org
>>>>>
https://www.ietf.org/mailman/listinfo/isis-wg
>>>>>
>>>>
>>>> _______________________________________________
>>>> Isis-wg mailing list
>>>>
Isis-wg at ietf.org
>>>>
https://www.ietf.org/mailman/listinfo/isis-wg
>>>>
>>>
>>> _______________________________________________
>>> rbridge mailing list
>>>
rbridge at postel.org
>>>
http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>>
>>
>>
>
> _______________________________________________
> Isis-wg mailing list
>
Isis-wg at ietf.org
>
https://www.ietf.org/mailman/listinfo/isis-wg
>