Subject: [Teas] A unified draft on resource scheduling

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 10 May 2016 13:41:43 +0100

Hi All,

In Yokohama two I-Ds were presented that showed different approaches to managing
scheduled resource usage in TE networks. Since then the authors of the two
drafts have spent time discussing the best way forward to merge their ideas.

We have now reached that point and posted a new revision of one of the drafts
(see below) that we are all happy with as an overall architecture.

We think that the WG in Yokohama expressed an interest in having this sort of
document to record consensus on how to handle resource scheduling and serve as a
basis for any protocol extension work.

If that is right, we believe that this document is now ready for the WG to
consider for adoption and to develop into a TEAS RFC.

Please review and let us know your thoughts.

Chairs: any next steps for adoption?

Thanks,
Adrian

> -----Original Message-----
> From: I-D-Announce [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 10 May 2016 10:16
> To: [email-masked]
> Subject: I-D Action: draft-zhuang-teas-scheduled-resources-02.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> 
> 
>         Title           : Architecture for Scheduled Use of Resources
>         Authors         : Yan Zhuang
>                           Qin Wu
>                           Huaimo Chen
>                           Adrian Farrel
> 	Filename        : draft-zhuang-teas-scheduled-resources-02.txt
> 	Pages           : 13
> 	Date            : 2016-05-10
> 
> Abstract:
>    Time-Scheduled reservation of traffic engineering (TE) resources can
>    be used to provide resource booking for TE Label Switched Paths so as
>    to better guarantee services for customers and to improve the
>    efficiency of network resource usage into the future.  This document
>    provides a framework that describes and discusses the architecture
>    for the scheduled reservation of TE resources.  This document does
>    not describe specific protocols or protocol extensions needed to
>    realize this service.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-zhuang-teas-scheduled-resources/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-zhuang-teas-scheduled-resources-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-zhuang-teas-scheduled-resources-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 12 May 2016 11:04:14 +0000

I wonder why Section 3.1 does not mention that central storage may have scaling limitations as well, even if this may not really change the overall tradeoff between the two approaches.

I believe it would make sense to also look at the implications of "a busy network with a high arrival rate of new LSPs and a low hold time for each LSP" for the centralized case, to have a more balanced discussion. While it may be true that the centralized approach scales better, e.g., because it can better leverage modern DB technology, any persistent storage of huge amounts of possibly highly dynamic data does not come entirely for free, right?

Michael

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of EXT Adrian Farrel
Sent: Tuesday, May 10, 2016 2:42 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Teas] A unified draft on resource scheduling

Hi All,

In Yokohama two I-Ds were presented that showed different approaches to managing scheduled resource usage in TE networks. Since then the authors of the two drafts have spent time discussing the best way forward to merge their ideas.

We have now reached that point and posted a new revision of one of the drafts (see below) that we are all happy with as an overall architecture.

We think that the WG in Yokohama expressed an interest in having this sort of document to record consensus on how to handle resource scheduling and serve as a basis for any protocol extension work.

If that is right, we believe that this document is now ready for the WG to consider for adoption and to develop into a TEAS RFC.

Thanks,
Adrian

directories.
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 13 May 2016 10:46:34 +0000

Hi,

   This is good draft, thanks for consolidating. 

   I have one suggestion that IMHO can improve the document. If we can
   display TS-TED and TS-LSP-DB as a separate component (of course
   implementation can choose to implement them together) would help in
   highlighting which part is new and which, already exist (such as
   the interfaces (d), (e), (f) and now (b1) and (c1) ).   

             -------------------
            | Service Requester |
             -------------------
                        ^
                       a|
                        v
                     -------   b1  --------
                    |       |<--->| LSP-DB |
                    |       |      --------
                    |  PCE  |  b2     -----------
                    |       |<------>| TS-LSP-DB |
                    |       |         -----------
                    |       |
                    |       |  c1   -----
                    |       |<---->| TED |
                    |       |       -----
                    |       |  c2     --------
                    |       |<------>| TS-TED |
                    |       |         --------
                     -------
                     ^     ^
                     |     |
                    d|     |e
                     |     |
               ------+-----+--------------------
                     |     |          Network
                     |     --------
                     |    | Router |
                     v     --------
                   -----          -----
                  | LSR |<------>| LSR |
                   -----     f    ----- 

   Some other comments - 

   (1) We can explicitly highlight the benefit of this architecture 
   v/s doing time-scheduling at NMS/OSS layer. 

   (2) In section 2.4 which describes Requisite state information 
   can we also describe the future LSP state that needs to be 
   maintained, most of the description that exist for resource on each 
   link is also applicable to future LSP (for ex. Start time, end 
   time, cycle etc)

Thanks! 

Dhruv

> From: Teas [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 10 May 2016 18:12
> To: [email-masked]
> In Yokohama two I-Ds were presented that showed different approaches to
> managing scheduled resource usage in TE networks. Since then the authors
> of the two drafts have spent time discussing the best way forward to merge
> their ideas.
> 
> We think that the WG in Yokohama expressed an interest in having this sort
> of document to record consensus on how to handle resource scheduling and
> serve as a basis for any protocol extension work.
> 
> If that is right, we believe that this document is now ready for the WG
> to consider for adoption and to develop into a TEAS RFC.
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 13 May 2016 17:14:56 +0100

Hello Michael,

> I wonder why Section 3.1 does not mention that central storage may have
scaling
> limitations as well, even if this may not really change the overall tradeoff
> between the two approaches.
> 
> I believe it would make sense to also look at the implications of "a busy
network
> with a high arrival rate of new LSPs and a low hold time for each LSP" for the
> centralized case, to have a more balanced discussion. While it may be true
that
> the centralized approach scales better, e.g., because it can better leverage
> modern DB technology, any persistent storage of huge amounts of possibly
> highly dynamic data does not come entirely for free, right?

Yes, this is a reasonable point and I have it on the list for the next revision
(unless you want to suggest text :-)

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 13 May 2016 17:33:23 +0100

Hi Dhurv,

Thanks for your thoughts.

>    the interfaces (d), (e), (f) and now (b1) and (c1) ).

If I read this right you are pointing out that the data stored might be split
into "the current state of the network" and "future plans".

That's a fair point. I would prefer to not complicate the diagram and thereby
imply that that split is required in an implementation, but I think the text
should point out that this is separate data. We'll work on it.

>    v/s doing time-scheduling at NMS/OSS layer.

Yes. The comparison is so stark that I think it never occurred to us to make it.
But it is simple to add and explain that scheduling without a view of the
network or an understanding of how services might be placed in the network is
likely to result in late surprises or suboptimal network use.

>    link is also applicable to future LSP (for ex. Start time, end

Yes. I have some concerns about the information model in particular because the
way the information is held to facilitate an implementation (i.e., the data
models) may be very different from how the information is held in permanent
storage. But I think you are right that the planned LSPs also need to be held
(if for no other reason than the PCE must cause them to be initiated later!)

Thanks,
Adrian

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 16 May 2016 03:42:51 +0000

Hi Adrian, 

I agree with all your suggested resolutions. Looking forward to the next update. 
I support putting this work for WG adoption. 

Thanks!
Dhruv

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: 13 May 2016 22:03
> To: Dhruv Dhody <[email-masked]>; [email-masked]
> Subject: RE: [Teas] A unified draft on resource scheduling
> 
> Hi Dhurv,
> 
> network or an understanding of how services might be placed in the network
> is likely to result in late surprises or suboptimal network use.
> 
> Yes. I have some concerns about the information model in particular because
> the way the information is held to facilitate an implementation (i.e., the
> data
> storage. But I think you are right that the planned LSPs also need to be
> held (if for no other reason than the PCE must cause them to be initiated
> later!)
> 
> Thanks,
> Adrian
>