Hi Alia When I read through this thread I question data Model that is being described.
If the model reports the TE parameters themselves then you have summaries of BW etc. And you know little about the true resource profile. But if the Model supports something like (forgive the pseudo syntax.) Object[RSVP-TE Session ID] Ingress Link[i/f ID], Label, egress Link[i/f ID], Label, BW 2 Mb Object[RSVP-TE Session ID] Ingress Link[i/f ID], Label, egress Link[i/f ID], Label, BW 5 Mb ... Then one could construct a much better model of TE parameters. The reason we never did that for TE parameters was because Routing had to summarize in order to scale. Are we planning to limit the I2RS model this way too? Or would this TE information be augmented with more detail by some other means? Thanks, Don From: i2rs [mailto:[email protected]] On Behalf Of Alia Atlas Sent: Thursday, January 09, 2014 6:00 PM To: Greg Mirsky Cc: [email protected]; Russell Harrison; Dhruv Dhody; Guanxiaoran Subject: Re: [i2rs] TED extension in topology info model (WG chair hat off) For those not familiar, the proposed additional attributes are coming from draft-ietf-ospf-te-metric-extensions-05. It makes sense to me that the topology sub-models would include this type of information. Alia On Thu, Jan 9, 2014 at 5:57 PM, Greg Mirsky <[email protected]<mailto:[email protected]>> wrote: Hi Dhruv, et al., I think that your explanation of Residiual BW and BW Utilization fields clearly indicates that these, as well as related to timing, are rather part of Performance Measurement info and as such depends upon measuring instruments. For example, measuring Link Delay use active or passive method? If active, what could be size of test packet? Variable or not? Though PM is very interesting subject, I believe that inclusion of dynamically measured in-service performance parameters would only destabilize the topology while adding little value. I think that PM is more useful on Service rather than Link level. Regards, Greg On Thu, Jan 9, 2014 at 2:13 AM, Dhruv Dhody <[email protected]<mailto:[email protected]>> wrote: From: i2rs [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Russell Harrison Sent: 09 January 2014 15:26 To: Guanxiaoran Cc: [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
