[email protected]
[Top] [All Lists]

Re: composite link - candidate for respin, maybe

Subject: Re: composite link - candidate for respin, maybe
From: Curtis Villamizar
Date: Tue, 30 Mar 2010 00:44:10 -0400
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
> latency).
> 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
> scalability.
> 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?
> Tony


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
[email protected]

<Prev in Thread] Current Thread [Next in Thread>