Pseudonode Reduction in ISIS draftisispseudoperlmanroythomas00 txt Matthew R

Pseudonode Reduction in IS-IS draft-isis-pseudo-perlman-roy-thomas-00. txt Matthew R Thomas mrthom@essex. ac. uk 9 th March 08 71 st IETF Meeting

Pseudonode overview • Pseudonodes are useful with more than 4 nodes. • With only 2 nodes, they are dramatically wasteful. • 50% increase in nodes, more LSPs, costs to CPU, Bandwidth and memory 9 th March 08 71 st IETF Meeting

TRILL Topologies and Pseudonodes: • Initially with RBridges mixed with lots of bridges, there are likely to be "links" with large numbers of RBridges -- clearly initially there is a need for pseudonodes in those cases. • Once TRILL is well deployed, it is expected that almost all links will be pt-to-pt between RBridges 9 th March 08 71 st IETF Meeting

TRILL deployment • TRILL is aimed at deployment in locations that are comfortable with zero configuration. This is partly why RBridges are being used and not routers 9 th March 08 71 st IETF Meeting

Setting reduction limits • We are recommending using a pseudonode for any link with more than two nodes. • Even though in theory it's a little wasteful to use a pseudonode with 3 nodes, on balance it seems reasonable to set the limit to three for use of pseudonode. 9 th March 08 71 st IETF Meeting

Simple operation • We are not talking about changing how flooding is done on the link-- just how the link is represented in the link state database • DIS election, flooding, and the use of CSNP’s and PSNP’s remain unchanged on the link. 9 th March 08 71 st IETF Meeting

Pseudonode operation • A broadcast network with a pseudonode with two routers, R 1 (DR) and R 2: R 1's LSP says "I'm attached to R 1. 25" R 2's LSP says "I'm attached to R 1. 25“ R 1. 25's LSP says "I’m attached to R 1 and R 2" 9 th March 08 71 st IETF Meeting

Pseudonode reduction mechanism • Without the reduction mechanism, then in this case R 1's LSP says "I'm attached to R 2“ R 2's LSP says "I'm attached to R 1“ • Local operation of the link remains the same 9 th March 08 71 st IETF Meeting

NS and SS flags • Two flags are used; NS (pseudonode suppression capable) and SS (suppress pseudonode) • The NS bit indicates the pseudonode suppression capability. • All routers set this in their Hello for the link if they are pseudonode reduction capable • The proposed TLV needs to be attached to the Hello 9 th March 08 71 st IETF Meeting

NS and SS flags cont • If ALL neighbors have the NS bit set in the Hello packet concerning the link then The DIS may decide to use pseudonode reduction. • The DIS then sets the SS bit to signal to the routers to use pseudonode reduction • We are proposing using Link Attribute sub-TLV 19 (RFC 5029) • This sub-TLV is part of TLV 22 (RFC 3784) 9 th March 08 71 st IETF Meeting

Setting and Resetting the SS bit • The link starts with no pseudonode and the DIS monitors the NS bit of the neighbors on the link. • If there are <=2 ISIS nodes (ie; one neighbor) on the link then the DIS may use pseudonode reduction. • If a third node arrives then the DIS resets the SS bit and cancels the pseudonode reduction. 9 th March 08 71 st IETF Meeting

Options with resetting the SS bit • Option 1: Regardless of the loss of connectivity with one of the neighbors, the pseudonode reduction is not re-instated. • Option 2: A variant is to have a *long* hysteresis, perhaps 2 hours, and if there remains no 3 rd node then pseudonode reduction can be re-instated. • Option 3: Have a simple upper and lower threshold, with stable state in-between. ie; Reduction off if >= 3, and on if = 2 9 th March 08 71 st IETF Meeting

Advantages / Disadvantages • Option 1: – Disadvantage: Could end up with permanent pseudonode where it wasn’t required – Advantage: Stability, and reduction of pseudonode in most cases. • Option 2: – Disadvantage: Possible pseudonode flapping – Advantage: Less LSA’s if a router is removed permanently. • Option 3: – Disadvantage: variant on option 2 – Advantage: variant on option 2 9 th March 08 71 st IETF Meeting

Options considered for NS / SS location • Option 1: Proposed solution sub-TLV – The information is link specific. The sub-TLV can be used with TLV 22 and is standardised. – Permission required to place this TLV in the ISIS Hello packets • Option 2: Router Capability TLV 242 (RFC 4971) – Using this TLV field was not possible – The information is link specific. Although a router may have the same capability on all Ethernets the SS bit may be different on each link depending on the location of non-compatible nodes. • Option 3: Use of specific bits in ISIS Hello – Require changes to ISIS hello packet structure / new TLV in ISIS Hello packet. 9 th March 08 71 st IETF Meeting

WG Issues 9 th March 08 71 st IETF Meeting