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 11 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 11 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 11 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 11 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. 11 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. 11 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" 11 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 11 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 11 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) 11 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. 11 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 11 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 11 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. 11 th March 08 71 st IETF Meeting

WG Issues 11 th March 08 71 st IETF Meeting