Having the worst time with this device sending half-written messages. I'm not convinced that it's desirable to store live interface stats in the TED. This would lead to significant additional load without much additional utility.
RSVP-TE tracks it's reservations per interface anyway, and has provisions to ensure that only those LSPs for which sufficient bandwidth is available can successfully signal Sent from my iPhone On Jan 9, 2014, at 4:14 AM, Dhruv Dhody <[email protected]> wrote: *From:* i2rs [mailto:[email protected] <[email protected]>] *On Behalf Of *Russell Harrison *Sent:* 09 January 2014 15:26 *To:* Guanxiaoran *Cc:* [email protected] *Subject:* Re: [i2rs] TED extension in topology info model 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. *[DD] Hmmm I disagree. * *All 3 fields maybe used as they have subtle differences. * *Residual BW = Maximum Bandwidth minus the bandwidth currently *allocated* to RSVP-TE LSPs.* *Available BW = Residual bandwidth minus the measured bandwidth *used* for the actual forwarding of non-RSVP-TE LSP packets. * *BW Utilization = the actual utilization of the link (i.e.: as measured in the router including both RSVP and non-RSVP)* The other two could be calculated (not to mention, in this context residual and available probably mean he same thing. *[DD] “*residual and available*” are different, as above! * 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? *[DD] Maybe we should have - [<TE_Performance_Info>] making it optional?* *Regards,* *Dhruv* 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
