In message <C7D665BD.919B%[email protected]>
Tony Li writes:
> Hi John,
> > The difference between advertising one bundled link with multiple sets
> > of parameters or multiple bundled links each with one set of
> > parameters doesn't seem so significant.
> Well, that depends entirely on our scalability goals, which is why I would
> like to see our requirements quantified.
> As an example, if we use IS-IS with TE right now, a link consists of:
> 2 octets of TLV overhead
> 7 octets of system Id and pseudonode number
> 3 octets of default metric
> 1 octet of length of sub-TLVs
> 6 octets of Administrative group (color)
> 6 octets of IPv4 interface address
> 6 octets of IPv4 neighbor address
> 6 octets of Maximum link bandwidth
> 6 octets of Reservable link bandwidth
> 34 octets of Unreserved bandwidth (for 8 traffic classes)
> 5 octets of TE Default metric
> If we want to track latency, then I'd propose that we need 3 bytes to track
> worst case latency on the link (2 bytes overhead, 1 byte for ms granularity
> If I've done my math right, that works out to 85 bytes.
> If we then vectorize this, we would need, per component:
> 4 octets of maximum link bandwidth
> 4 octets of reservable link bandwidth
> 32 octets of unreserved bandwidth
> 1 octet of latency
> That's 41 bytes.
> If we're willing to dispense with pre-reserved bandwidth per traffic class,
> then we can further drop 32 octets.
> So we're down to 9 bytes per link, or almost a 10x improvement in
> IMHO, that's significant.
> If we now have ~16 components per composite link, then we can advertise the
> composite link in about 200 bytes. That works out to well over 1000
> composite links (and therefore 16,000 components) per system. And that's
> before we break a sweat and do funky things to get more LSP space (e.g.,
> expanded MTUs, zero-cost pseduonodes for more fragments).
> So, what are the real requirements?
Its not just about whether it fits into the available set of LSPDU.
Every time a new LSP is signaled reservable bandwidth changes and it
could potentially mean another advertisedment of a bloated LSPDU
fragment (or a much smaller but still bloated opaque LSA).
This can be a big problem after a fault has occurred, particularly a
fault involving more than one SRLG where protection also failed.
rtgwg mailing list