Moving to a new thread, since the "Why is MTU discovery important"
thread
was getting too long (and the subject line had nothing to do with most
of the discussion).
Hopefully we can quickly close the issue of DRB election/MTU
discovery.
And then finally close on the base protocol document...
I was participating in an off-list
group of people discussing the issue, which was useful in clarifying
certain aspects.
I will summarize the proposed solution.
First, refreshing people as to what the issue is:
The problem: The Hello protocol in IS-IS may elect multiple
DRs, since routers ignore routers with whom they do not have
2-way connectivity. Somewhat orthogonally, IS-IS LAN
Hellos are padded, to avoid forming adjacencies with neighbors
that you can't speak the minimum acceptable size with.
This behavior is fine for layer 3, but not for layer 2, where
it will form loops if there are multiple DRBs.
So ignoring this issue for TRILL is not an option.
***********************
A bit of background on IS-IS
IS-IS is modular, in that there are two sublayers, that
in DECnet we called the "subnetwork independent sublayer"
and the "subnetwork dependent sublayer". The subnetwork
dependent sublayer has neighbor adjacency forming protocols
for different types of links.
What we are proposing for TRILL is support for a new type
of link within IS-IS's "link dependent sublayer". This
is for Ethernet links that are not explicitly pt-to-pt.
What we need to accomplish with this protocol:
a) elect exactly one DRB
b) figure out what the campus-wide minimum MTU size, "S", is (to know
what the minimum acceptable link MTU size is). LSP fragment
sizes must not be larger than this minimum
c) test neighbor-neighbor links to see if they support size S
d) remove links from the topology that do not support the
campus minimum size S
*****************************
Electing exactly one DRB
This will be based on periodic messages, which we'll
call TRILL-Hellos, similar to IS-IS
LAN Hellos, but they are different in two aspects: they are
not padded, and election is based solely on (ID, priority), and
not on whether connectivity is 2-way. In other words, R2
defers to R1 if R1 has higher (ID, priority), whether or
not there is 2-way connectivity between R2 and R1.
TRILL-Hellos must be periodic and frequent, so as
to avoid having RBs not know about each other. They will be
sent on the set of VLANs that the TRILL spec already says Hellos
would be sent on.
TRILL-Hellos contain all the same information
that the TRILL spec already claims is in Hello messages. (other
than the difference that they won't be padded).
So basically, the changes in the TRILL spec so far are
1) rename Hello to "TRILL-Hello message"
2) do not pad the message
3) election will be based solely on the fields (ID, priority).
Note: Although the neighbor list is included in a TRILL-Hello, (as
it is in
an IS-IS LAN Hello), it does not affect selection of DRB.
But the neighbor list still needs to be there
for all the RBridges to
know which neighbors they have 2-way connectivity with, for the
purpose of reporting links in LSPs.
*******************************
figuring out what the campus-wide minimum MTU size is:
This will be done based on a TLV in LSPs (which already
exists in IS-IS -- the originatingLSPBufferSize, TLV 14).
If that TLV is absent,
it is the same as requesting "1470". The campus-wide minimum MTU size
chosen is the smallest size "S" reported in any LSP.
LSP fragments must not be bigger than S, and links that cannot
support S will not appear in the topology (meaning, they will not
be reported in LSPs)
***************************************************
testing neighbor-neighbor links to ensure they support "S".
We will have new messages: MTU probe, and MTU ack. Both
are padded to size S.
It will be optional whether and when to send an MTU
probe, but mandatory to send an ack in response to receipt
of an MTU probe. The ack is padded to the same size that the
probe was padded to, and is unicast to the RBridge from
which the probe was received. Probes may be unicast or
multicast. They may be sent periodically (but far less
frequently than DRB election messages). Or they might be
sent only in response to an event such as hearing from
a new neighbor RBridge. Both MTU probes and acks are
sent only on the Designated VLAN.
If R1 fails to get an ack from R2, R1 still reports R2 in
its neighbor list, but with a flag saying "failed minimum MTU test".
****************
Links that are not 2-way for any reason, including not
supporting the minimum campus-wide MTU S, are not reported in LSPs.
That means that if R1 is DRB, and it does not have 2-way connectivity
to R2, R1 does not list R2 as a neighbor, in the pseudonode LSP.
R2 does not report a link to the pseudonode.
If neither R2 nor R3 are DRB, they both have 2-way connectivity to
the DRB, but not to each other, then they do both report
connectivity to the pseuodnode. However, if R2 receives
a packet that needs to be forwarded to R3 across that link, R2
sends the packet to the DRB instead. (Note: This behavior is
already specified in IS-IS)
*******************
Concern was raised about the size of TRILL-hellos. Might they wind
up being
too big to fit? This concern would apply whether Hellos are padded
or not.
For instance, one topology
people envision is a core that connects hundreds of customer sites
into a giant Ethernet. The technology that creates the core is
irrelevant to TRILL, other than having Ethernet-like
characteristics, in
terms of being multiaccess and supporting multicast.
In that case, if the customer's Ethernet
is running TRILL, the core would appear to TRILL to be a giant
Ethernet with
hundreds of neighbors. In other words, all the hundreds of RBridges
connected to the core would see all of the other RBridges on the core
as neighbors on this "link".
IS-IS has carefully designed packet formats for LSPs and CSNPs, so
that they can be arbitrarily large, transmitted in pieces, with each
piece being able to be independently processed. For some reason
though we didn't design Hellos that way. We should take the
opportunity to design TRILL-Hello messages with that effect.
There are some things in TRILL-Hellos that don't really need to
be reported frequently (like which VLANs you support). And some things
(like the neighbor list) that might wind up being too large to fit
into a single packet.
Other information (such as ID and priority) really should go in every
TRILL-Hello.
I'd suggest we do two things in the encoding of TRILL-Hellos
a) figure out which fields can be left out some of the time,
and specify that those fields, if absent, just mean they
are absent, not, for instance, that you don't support any VLANs.
b) for information like the neighbor list that can be
arbitrarily large, figure out a way of encoding it in the
spirit of CSNPs, so that partial information can be included.
For instance, CNSPs say "this CSNP refers to all the LSPs from
IDs between x and y". We could do the same for the TRILL-Hellos,
as in "this TRILL-Hello neighbor list includes all neighbors
with IDs between x and y".
***********************************
Radia
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge