Hi again Richard, We are in no rush. It is better to have some considered and structured text in March than hurried text later today. It will be interesting to debate the formation of the TED and LSP-DB using ALTO. I believe this discussion starts to overlap with your potential rechartering and needs to be resolved through a discussion with the Routing Area. that does not mean: - ALTO is the wrong protocol for this - we should not discuss it in this document We do, however, have to draw a careful line between what can be done and what could be done. Looking forward to seeing text. Cheers, Adrian From: [email protected] [mailto:[email protected]] On Behalf Of Y. Richard Yang Sent: 13 February 2014 18:39 To: [email protected] Cc: IETF ALTO Subject: Re: [alto] Some help wrt ALTO and draft-farrkingel-pce-abno-architecture-07.txt Hi Adrian, Excellent document by you and Daniel! I see several potential places where you might be considering ALTO WG contribution. Hence, let us understand the setting a bit better: - 1. I see some usage of ALTO Services in early part of the document. For example, Sec. 3.1: there will be 16 paths: 2 (s -> a1 or s -> a2) x 4 (a1/b1 -> b3/c1, a1/b1 -> b4/c2, a2/b2 -> b3/c1, a2/b2 -> b4/c2) x 2 x ALTO Servers serving the three domains can provide the end-to-end costs so that the higher layer can build a virtual topology to preselect the high-level paths, where the high-level topology has 6 nodes (s, a1/b1, a2/b2, ...) and link costs coming from ALTO. - Sec. 3.8.3. One example use case we are thinking is that an ALTO Server extracts TED/LSP-DBs, computes ALTO abstract topology Information to an application guided by the Policy Agent, application computes paths according to the abstract ALTO topology information, and requests setting up the paths through ABNO, who consults PCE/ALTO (need a link from ABNO Controller/PCE to ALTO in Figure 1) to map the paths back to real topology. Some contributors will be more than happy to contribute in either sense. Which one do you prefer? A realistic "valentine" commitment will be Feb. 24 :-) Thanks! Richard On Thu, Feb 13, 2014 at 7:07 AM, Adrian Farrel <[email protected]> wrote: Hi ALTO WG,
Our draft pulling together a number of existing IETF components into a single architecture for application-based network operations is progressing nicely. In fact, it is almost cooked. We see ALTO as one of the important components, but we are a bit short of words about ALTO. Would anyone care to volunteer to provide words for section 3.8.3? We are looking for about two pages of high-level text covering the purpose of the use case, the flow of control between ABNO components, and maybe a figure or two. compare with 3.1, 3.2, etc. for an idea of the material needed. Thanks, Adrian and Dan > -----Original Message----- > From: I-D-Announce [mailto:[email protected]] On Behalf Of > [email protected] > Sent: 13 February 2014 11:50 > To: [email protected] > Subject: I-D Action: draft-farrkingel-pce-abno-architecture-07.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : A PCE-based Architecture for Application-based Network > Operations > Authors : Daniel King > Adrian Farrel > Filename : draft-farrkingel-pce-abno-architecture-07.txt > Pages : 62 > Date : 2014-02-13 > > Abstract: > Services such as content distribution, distributed databases, or > inter-data center connectivity place a set of new requirements on the > operation of networks. They need on-demand and application-specific > reservation of network connectivity, reliability, and resources (such > as bandwidth) in a variety of network applications (such as point-to- > point connectivity, network virtualization, or mobile back-haul) and > in a range of network technologies from packet (IP/MPLS) down to > optical. An environment that operates to meet this type of > requirement is said to have Application-Based Network Operations > (ABNO). > > ABNO brings together many existing technologies for gathering > information about the resources available in a network, for > consideration of topologies and how those topologies map to > underlying network resources, for requesting path computation, and > for provisioning or reserving network resources. Thus, ABNO may be > seen as the use of a toolbox of existing components enhanced with a > few new elements. The key component within an ABNO is the Path > Computation Element (PCE), which can be used for computing paths and > is further extended to provide policy enforcement capabilities for > ABNO. > > This document describes an architecture and framework for ABNO > showing how these components fit together. It provides a cookbook of > existing technologies to satisfy the architecture and meet the needs > of the applications. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-farrkingel-pce-abno-architecture/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-farrkingel-pce-abno-architecture-07 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto -- -- ===================================== | Y. Richard Yang <[email protected]> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =====================================
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
