Hi Don, On Tue, Jan 21, 2014 at 4:32 PM, Fedyk, Don <[email protected]> wrote:
> 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? > > Good question! In the context of the information model for topology produced via ISIS, OSPF, or BGP-LS, I2RS can't really provide more information than the underlying protocol has. In general, in the architecture (new draft version in progress), the idea of a "service" and associated information model for RSVP-TE is there. In that context, I can certainly see the above being useful to provide. We don't have anyone volunteering yet (that I know of) to write down some ideas for the RSVP-TE information model... Regards, Alia > > > 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]> 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
