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