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]> wrote: > *From:* i2rs [mailto:[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 > >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
