Subject: Re: [Isis-wg] [rbridge] Proposed resolution of DRB election/MTU testing

From: David Ward <[email-masked]>
Date: Thu, 30 Apr 2009 13:45:41 -0500

Radia -

It seems like we are at the point of writing this into draft-l2isis.  
This is good news.

Thanks for helping to drive the discussion.

-DWard

On Apr 29, 2009, at 11:21 PM, Radia Perlman wrote:

> 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
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge