Subject: [i2rs] TED extension in topology info model

From: Guanxiaoran <[email-masked]>
Date: Thu, 9 Jan 2014 09:18:59 +0000

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?

Regards,
Ran

---

From: Russell Harrison <[email-masked]>
Date: Thu, 9 Jan 2014 03:55:54 -0600

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. The other two could be
calculated (not to mention, in this context residual and available probably
mean he same thing.

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-masked]> wrote:

    Hi ,

[draft-medved-i2rs-topology-im-01] defines a TED (Traffic Engineering Data)
component ([RFC5305], [RFC3630]):

<ted-link> ::= <COLOR>

                     <MAX_LINK_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>

                     <TE_DEFAULT_METRIC>

<TE_Performance_Info>

                     [<srlg-attributes>]

                                                   <Min/Max Unidirectional
Link Delay>

                                                   <Unidirectional Delay
Variation>

                                                   <Unidirectional Packet
Loss>

                                                   <Unidirectional Residual
Bandwidth>

                                                   <Unidirectional
Available Bandwidth>

What do you think?

Regards,

Ran

_______________________________________________
i2rs mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2rs

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 9 Jan 2014 10:13:43 +0000

From: i2rs [mailto:[email-masked]] On Behalf Of Russell Harrison
Sent: 09 January 2014 15:26
To: Guanxiaoran
Cc: [email-masked]
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-masked]<mailto:[email-masked]>> wrote:
Hi ,

What do you think?
[DD] Maybe we should have -  [<TE_Performance_Info>] making it optional?

Regards,
Dhruv

Regards,
Ran
_______________________________________________
i2rs mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2rs

---

From: Russell Harrison <[email-masked]>
Date: Thu, 9 Jan 2014 04:45:23 -0600

Your definition for available is interesting - it would seem more intuitive
to represent that as "residual - excess tx rate" ... If accepted as you
described, in profile traffic isn't counted.

Sent from my iPhone

On Jan 9, 2014, at 4:14 AM, Dhruv Dhody <[email-masked]> wrote:

    *From:* i2rs [mailto:[email-masked] <[email-masked]>] *On
Behalf Of *Russell Harrison
*Sent:* 09 January 2014 15:26
*To:* Guanxiaoran
*Cc:* [email-masked]
*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! *

-rh

Sent from my iPhone

  Hi ,

<ted-link> ::= <COLOR>

                     <MAX_LINK_BANDWIDTH>

                     <TE_DEFAULT_METRIC>

                     [<srlg-attributes>]

<ted-link> ::= <COLOR>

                     <MAX_LINK_BANDWIDTH>

                     <TE_DEFAULT_METRIC>

<TE_Performance_Info>

                     [<srlg-attributes>]

                                                   <Min/Max Unidirectional
Link Delay>

                                                   <Unidirectional Delay
Variation>

                                                   <Unidirectional Packet
Loss>

                                                   <Unidirectional Residual
Bandwidth>

                                                   <Unidirectional
Available Bandwidth>

What do you think?

*[DD] Maybe we should have -  [<TE_Performance_Info>] making it optional?*

*Regards,*

*Dhruv*

Regards,

Ran

---

From: Russell Harrison <[email-masked]>
Date: Thu, 9 Jan 2014 04:42:42 -0600

Point taken. If

Sent from my iPhone

*[DD] Hmmm I disagree. *

-rh

Sent from my iPhone

  Hi ,

<ted-link> ::= <COLOR>

                     <MAX_LINK_BANDWIDTH>

                     <TE_DEFAULT_METRIC>

                     [<srlg-attributes>]

<ted-link> ::= <COLOR>

                     <MAX_LINK_BANDWIDTH>

                     <TE_DEFAULT_METRIC>

<TE_Performance_Info>

                     [<srlg-attributes>]

                                                   <Min/Max Unidirectional
Link Delay>

                                                   <Unidirectional Delay
Variation>

                                                   <Unidirectional Packet
Loss>

                                                   <Unidirectional Residual
Bandwidth>

                                                   <Unidirectional
Available Bandwidth>

What do you think?

*Regards,*

*Dhruv*

Regards,

Ran

---

From: Russell Harrison <[email-masked]>
Date: Thu, 9 Jan 2014 04:52:32 -0600

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

*[DD] Hmmm I disagree. *

-rh

Sent from my iPhone

  Hi ,

<ted-link> ::= <COLOR>

                     <MAX_LINK_BANDWIDTH>

                     <TE_DEFAULT_METRIC>

                     [<srlg-attributes>]

<ted-link> ::= <COLOR>

                     <MAX_LINK_BANDWIDTH>

                     <TE_DEFAULT_METRIC>

<TE_Performance_Info>

                     [<srlg-attributes>]

                                                   <Min/Max Unidirectional
Link Delay>

                                                   <Unidirectional Delay
Variation>

                                                   <Unidirectional Packet
Loss>

                                                   <Unidirectional Residual
Bandwidth>

                                                   <Unidirectional
Available Bandwidth>

What do you think?

*Regards,*

*Dhruv*

Regards,

Ran

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 09 Jan 2014 07:34:31 -0600

Folks: Please move this conversation to the alto WG mailing list.
It appears to have more of a bearing on alto; i2rs served its
purpose and is an inert (thought not inactive) list.

Cheers,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: Alia Atlas <[email-masked]>
Date: Thu, 9 Jan 2014 10:23:12 -0500

Vijay,

No , that is completely inaccurate.  The topology export is specifically in
charter for I2RS.

Can you please explain the critical overlap you see with alto such that you
are trying to kill discussion on the I2RS making list?

(WG Chair hat firmly on)
Alia

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 09 Jan 2014 09:30:06 -0600

On 01/09/2014 09:23 AM, Alia Atlas wrote:
> Vijay,
>
> No , that is completely inaccurate.  The topology export is specifically
> in charter for I2RS.
>
> Can you please explain the critical overlap you see with alto such that
> you are trying to kill discussion on the I2RS making list?

Alia: Argh, I am sorry.  I mistook i2rs for i2aex mailing list!  The
i2aex was a BoF we did in the Paris IETF and in my email deluge this
morning, I conflated i2rs with i2aex.  It is the i2aex list that is
inert, having served its purpose.

Sorry for the interruption.  Please continue discussion as intended,
as I was not trying to kill any discussion on the i2rs mailing list.

I will make sure I get my first cup of coffee before responding :-)

Cheers, and again, much apologies.

- vijay

---

From: Alia Atlas <[email-masked]>
Date: Thu, 9 Jan 2014 10:40:42 -0500

Of course!  Glad and eager to have you join the conversation here.

Alia

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 9 Jan 2014 14:57:34 -0800

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-masked]> wrote:

>    *From:* i2rs [mailto:[email-masked]] *On Behalf Of *Russell
> Harrison
> *Residual BW =  Maximum Bandwidth minus the bandwidth currently
> *allocated* to RSVP-TE LSPs.*
>
> The other two could be calculated (not to mention, in this context
> residual and available probably mean he same thing.
>
> Residual Bandwidth>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 9 Jan 2014 18:00:26 -0500

(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-masked]> wrote:

> On Thu, Jan 9, 2014 at 2:13 AM, Dhruv Dhody <[email-masked]>wrote:
>
>> *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)*
>>
>>
>>

---

From: "Fedyk, Don" <[email-masked]>
Date: Tue, 21 Jan 2014 21:32:09 +0000

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-masked]] On Behalf Of Alia Atlas
Sent: Thursday, January 09, 2014 6:00 PM
To: Greg Mirsky
Cc: [email-masked]; 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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> wrote:
From: i2rs [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Russell Harrison
Sent: 09 January 2014 15:26
To: Guanxiaoran
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [i2rs] TED extension in topology info model

-rh

Sent from my iPhone

What do you think?

Regards,
Dhruv

Regards,
Ran

---

From: Alia Atlas <[email-masked]>
Date: Tue, 21 Jan 2014 16:43:43 -0500

Hi Don,

On Tue, Jan 21, 2014 at 4:32 PM, Fedyk, Don <[email-masked]> wrote:

> If the model reports the TE parameters themselves then you have summaries
> of BW etc.  And you know little about the true resource profile.
>
>
>
> …
> 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-masked]] *On Behalf Of *Alia Atlas
> *Sent:* Thursday, January 09, 2014 6:00 PM
> *To:* Greg Mirsky
> *Cc:* [email-masked]; Russell Harrison; Dhruv Dhody; Guanxiaoran
>