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 -DWardNote 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 makesure 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 foreversay that TRILL Hellos and LSPs cannot be bigger than that. MTU discovery would be done to ensure thatevery 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 TLVwould 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 linkscouldn't support 1450). _______________________________________________ Isis-wg mailing list Isis-wg at ietf.org https://www.ietf.org/mailman/listinfo/isis-wg