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