Looks ok in concept, but there's a great deal of redundancy in the performance info you describe. It seems that only one of the residual/available/utilized fields would be needed. The other two could be calculated (not to mention, in this context residual and available probably mean he same thing.
THe delay and loss fields are also interesting, assuming good methods to measure same are in place... -rh Sent from my iPhone On Jan 9, 2014, at 3:19 AM, Guanxiaoran <[email protected]> wrote: Hi , [draft-medved-i2rs-topology-im-01] defines a TED (Traffic Engineering Data) component ([RFC5305], [RFC3630]): <ted-link> ::= <COLOR> <MAX_LINK_BANDWIDTH> <MAX_RESV_LINK_BANDWIDTH> (<UNRESERVED_BANDWIDTH>...) <TE_DEFAULT_METRIC> [<srlg-attributes>] Besides the factors proposed in that document, other factors such as latency, limited bandwidth, packet loss, and jitter ([draft-ietf-isis-te-metric-extensions-01], [draft-ietf-ospf-te-metric-extensions-05], [draft-wu-idr-te-pm-bgp-03]), are all important that need to be taken into account in the topology info model. For example, shall we extend the TED component (i.e. including network performance information ) as follows: <ted-link> ::= <COLOR> <MAX_LINK_BANDWIDTH> <MAX_RESV_LINK_BANDWIDTH> (<UNRESERVED_BANDWIDTH>...) <TE_DEFAULT_METRIC> <TE_Performance_Info> [<srlg-attributes>] <TE_Performance_Info> ::= <Unidirectional Link Delay> <Min/Max Unidirectional Link Delay> <Unidirectional Delay Variation> <Unidirectional Packet Loss> <Unidirectional Residual Bandwidth> <Unidirectional Available Bandwidth> <Unidirectional Utilized Bandwidth> What do you think? Regards, Ran _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
