Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

[Khuzema Pithewan <[e-mail]>]

Hi Igor/Young/Daniele/Peter,

Out of 4 ACTN main functions, I see following 2 are required to be repeatable in the hierarchy and hence requires multi-level recursion.

1. virtualization/abstraction function
2. multi domain coordination function

Rest of the functions doesn’t need recursion because of their nature. 

a. customer mapping function 
b. virtual service coordination 

Both of the following functionality directly interfaces with Customer applications and requires them to directly pass on the series of commands to topology handler in order to realize a function of application.  However these 2 functions need resiliency / redundancy from customer application perspective and hence state coherency may be required across different instances of the modules that hosts these functions.


Physical network control has to be dedicated to one controller closest to NE and hence doesn't need hierarchy.

With this I would like to propose a different packaging of these 5 functions, based on their characteristics.

Would like to propose that -
1. virtualization and Multi-domain control function to be bundled into one component, which can be standardized in such a way that it can be hierarchical and forms the core of ACTN framework
2. Physical Network controller component can be built in such a way that it can interface with Virtualization and multi-domain controller on north side and controls NE towards south.
3. Customer mapping and virtual service co-ordination deals with Virtualization and multi-domain controller on south and interfaces with customer application on north.

To realize use-cases, where we don’t really have virtualization and there is no need of multi-domain control, we have 2 options :
Option#1 - Interface portion that deals with customer mapping function is designed in such a way that it can deal with virtual or physical topology in same way, as these use-cases won't need Virtual service coordination.
Option#2 - Make it possible to have virtualization and multi-domain control function as part of PNC.

I prefer option#1, as it simplifies architecture.

Thoughts?

Thanks
Khuzema

 

-----Original Message-----
From: ACTN [mailto:[e-mail]] On Behalf Of Igor Bryskin
Sent: Monday, December 22, 2014 5:36 AM
To: BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [e-mail]; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Young and Sergio,

Now the ACTN framework increasingly reminds me of the Barcelona FC lineup: here is Luis Suarez. He plays right forward position, but he can also play left and center forward. Here is Neymar. He can play all the positions as Suarez plus attacking midfielder, and here is Leo Messi, who can play any position! ;+) ! I understand why such redundancy in capabilities is necessary in football (injuries, fitness problems, red cards, etc.). But why one would need 50%+ redundancy in capabilities of distinct components in a network architecture? Can you give an example of any other network solution designed in IETF, ITU or anywhere else that has the same level of redundancy? Why any given ACTN component  should not be Messi with some of his skills disabled or not implemented if they are not necessary? For example, what does it mean "client" and "client mapping"? Can the client serve its own clients? If Yes, why the client is not , generally speaking, a MDSC?

Cheers, Merry Christmas and Happy New Year.
Igor

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[e-mail]]
Sent: Monday, December 22, 2014 5:43 AM
To: Leeyoung; Igor Bryskin
Cc: [e-mail]; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody; Victor Lopez
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

I think Young exactly pointed out what I tried to explain in my previous mail so I do not have much to add.
One of the basic use cases on which ACTN is focused is how to create a virtualized environment permitting to operators the view of an abstraction of the underlying multi-vendor, multi-admin and multi-technology network.
You do not need to export towards MSDC specif characteristics of your network but ACTN want to permit export of abstraction view .
This has to be standardize in the interface between MSDC and PNC not actual physical network resources. 
So, this restriction and scope is not idealistic but this orchestration functionality is what operator want.

Cheers and ...Merry Christmas and Happy New Year.

Sergio



-----Original Message-----
From: Leeyoung [mailto:[e-mail]]
Sent: venerdì 19 dicembre 2014 22:27
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [e-mail]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

I think there needs some clarification about what is PNC and what is MSDC. We define PNC as follows (Section 3.3): 

"The physical network controller is the one in charge of configuring the network elements, monitoring the physical topology of the network and passing it, either raw or abstracted, to the MDSC. ...
The PNC, in addition to being in charge of controlling the physical network, is able to implement two of the four ACTN main functionalities: multi domain coordination function and virtualization/abstraction function."

And MDSC as follows (Section 3.3):

"The MSDC (Multi Domain Service Coordinator) sits between the CNC (the one issuing connectivity requests) and the PNCs (Physical Network Controllers - the ones managing the physical network resources). The MSDC can be collocated with the PNC, especially in those cases where the service provider and the network provider are the same entity. ...
The MDSC is the only building block of the architecture that is able to implement all the four ACTN main functionalities, i.e. multi domain coordination function, virtualization/abstraction function, customer mapping function and virtual service coordination."

As Sergio pointed out, there are some duplicated functions between PNC and MSDC: (i) multi-domain coordination; (ii) virtualization/function while the MSDC performs two additional functionality interfacing the CNC: (i) customer mapping; (ii) virtual service coordination and the PNC performs network control of physical networks. 

With this definition, we can achieve what you describing. Please see in-line for my specific comment.

Thanks,
Young


-----Original Message-----
From: Igor Bryskin [mailto:[e-mail]]
Sent: Friday, December 19, 2014 2:34 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [e-mail]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Sergio,

In a single vendor environment it is Ok to separate MDSC function from PNC function (manipulating actual network resources) into separate physical locations and have the two entities talk to each other any way they want. Nor I have a problem to put both functions into the same box (BTW neither does   Daniele according to some of his emails). But this is beside the point. My problem is that you define in the ACTN architecture two distinct entities: MDSC and PNC. This entails a standardized interface between the two that would allow a vendor X MDSC to talk to a vendor Y PNC in terms of actual network resources the same way as to vendor Z PNC. I think this is an idealistic view: to me it is the same as to ask, for example, CIEN, INFN, ADVA, ALU, etc. to start supporting WSON RFCs. If this was possible, we would have by now a multi-vendor multi-domain GMPLS solution. The RFCs may be endorsed by CCAMP WG, but it does not mean that the vendors have actually implemented them and use in the products. Each of the vendors have different hardware and a lot of proprietary extensions imperative for provisioning of physical resources. 

YOUNG>> Vendor X MDSC can talk to Vendor Y PNC and Vendor Z PNC in abstracted view (not actual network resource) based on what we defined above. Again the PNC needs not send actual network resource info to MDSC. Rather, the PNC should send abstract network resource view to the MDSC. With this, multi-vendor controllers can interoperate with standard data model. 

 I do believe, though, that it is possible to get vendor X MDSC to talk to vendor Y or Z MDSC in terms of abstract (visualized) network resources. In other words, provider X and Y SDN controllers should see each other as MDSCs capable when necessary of either or both MDSC or/and PNC functions.

YOUNG>> Yes, this is the point I tried to come across in the above comment. 

Cheers,
Igor

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[e-mail]]
Sent: Friday, December 19, 2014 10:43 AM
To: Leeyoung; AshwoodsmithPeter; Igor Bryskin; Daniele Ceccarelli; Dhruv Dhody
Cc: [e-mail]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi all,

At first thanks to Igor and Peter to help discussion and in this way highlighting possible needs or gaps in the reference model proposed in the framework.

I share Young observations: Peter's illustration is very interesting but the fact to put an Hardware abstraction layer on MSDC is something would not be part of his role in the network. E.g. if I remember well hardware abstraction layer in the ONF architecture is on the NE of the network domain, it is very close to physical aspect of the network domain. If this would be one of the function on MSDC it is clearly not in the scope of the reference model proposed that start from the basic scope to create an entity strictly in relation with CNC (application level) to create an abstraction e2e view to simply network operation from client prespective.
We can certainly encompass everything at one level , but scalability and simplified view towards clients is not perceived .
Moreover , as mentioned in chapter 3 , and indicated by Daniele, some mails ago, it is not only a multi-domain coordination function in the scope of MSDC but there are 2 specific  functionality like "customer mapping function" and " virtual service coordination" that in our view are part of a more high entity with respect a controller like PNC. Encompassing all in only one entity can fall heavily  in both scalability and  CPU process requirement as mentioned  by Young.

Thanks
Sergio



-----Original Message-----
From: Leeyoung [mailto:[e-mail]]
Sent: venerdì 19 dicembre 2014 00:01
To: AshwoodsmithPeter; Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [e-mail]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Peter,

An interesting illustration! I agree with you on the code saving part. The code saving, however, would come at the expense of scalability if I understood correctly. This is exactly what operators want to avoid. 

Besides, the second one's MSDC would have need more CPU to process the larger data than the first one's MSDC. 

Thanks,
Young



-----Original Message-----
From: ACTN [mailto:[e-mail]] On Behalf Of AshwoodsmithPeter
Sent: Thursday, December 18, 2014 1:33 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [e-mail]
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Igor, playing devil's advocate-  in the case you describe the PCN control of the hub element could be through a dedicated PCN just for that NE. For example (and I hope the ASCII art survives the email mappings), given 7 network elements grouped into two domains and one hub (N4), we could treat the single hub as a domain by itself with its own PCN.

                 M S D N
                    |
    +---------------+---------------+       <-- I/F 'C'
    |               |               |
   PCN             PCN             PCN
    |               |               |
 +--+--+            |            +--+--+    <-- I/F 'D' 
 |  |  |            |            |  |  |
(N1,N2,N3)=========(N4)=========(N5,N6,N7)
          I.D.LINK    I.D.LINK


Alternatively if we treated the MSDN and PCN as the same 'thing', then the combined block has to have a hardware abstraction layer anyway so whatever is below that layer is logically a kind of PCN anyway EXCEPT it does not have to worry about topology abstraction. 

So the alternative requires the MSDNs to have some function X when they are talking directly to a bit of hardware i.e. don't speak the MSDN to MSDN I/F. I.E X is a kind of PCN 'light' (i.e. no abstraction capability).

                 M S D N
                 |  X  |
    +------------+  |  +------------+        
    |               |               |
  MSDN              |              MSDN
    X               |               X
 +--+--+            |            +--+--+      
 |  |  |            |            |  |  |
(N1,N2,N3)=========(N4)=========(N5,N6,N7)
          I.D.LINK    I.D.LINK

If one compares the two approaches in terms of the amount of code required, it's clear that there is a code savings with the second approach because there is only one block that is abstracting topology and passing it up, while with a totally separate PCN that type of code is replicated twice.

Are there other overlaps that disappear if MSDN and PCN are integrated? What are the disadvantages?

Peter

> -----Original Message-----
> From: Igor Bryskin [mailto:[e-mail]]
> Sent: Thursday, December 18, 2014 8:48 AM
> To: BELOTTI, SERGIO (SERGIO); AshwoodsmithPeter; Daniele Ceccarelli
> Cc: [e-mail]
> Subject: RE: [Actn] New Version Notification for
> draft-ceccarelli-actn- framework-05.txt
> 
> Hi Sergio,
> 
> I agree with what you said. This is especially true and apparent in 
> the configurations where the domains controlled by the subordinate 
> providers are interconnected not just by inter-domain links, but via 
> segments of accrual network. Consider, for example, the situation when 
> said domains are inter-connected in a star-n-spokes fashion with an 
> actual network element as the star. MDSC would the only entity in this 
> case to control it. So, esteemed fellow ACTNers:
> a) Generally speaking, MDSC needs to be able to control actual network 
> elements and links, and
> b) PNC needs to be able to perform multi-domain coordination (in case 
> it uses several subordinate PNCs of it's own)
> 
> This brings us back to the same question: where is the conceptual 
> difference between the two, and why do  they appear in the framework 
> as separate logical entities?
> 
> Cheers,
> Igor
> 
> 
> -----Original Message-----
> From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel- 
> lucent.com]
> Sent: Thursday, December 18, 2014 3:53 AM
> To: AshwoodsmithPeter; Daniele Ceccarelli
> Cc: Igor Bryskin; [e-mail]
> Subject: RE: [Actn] New Version Notification for
> draft-ceccarelli-actn- framework-05.txt
> 
> Hi Peter,
> 
> you're right : this functionality has to be part of "Multi domain 
> coordination function", and has has to be explicitly mentioned.
> 
> Thanks
> Sergio
> 
> 
> -----Original Message-----
> From: ACTN [mailto:[e-mail]] On Behalf Of 
> AshwoodsmithPeter
> Sent: mercoledì 17 dicembre 2014 21:38
> To: Daniele Ceccarelli; Igor Bryskin; [e-mail]
> Subject: Re: [Actn] New Version Notification for
> draft-ceccarelli-actn- framework-05.txt
> 
> Hey Daniele,
> 
> A few very minor typos and a simple question.
> 
> Page3 "such that resource guarantee" should be "such that resource 
> guarantees"
> Page6 "bundle of voice service" should be "bundle of voice services"
> Page6 "and they generally has very few" should be "and they generally 
> have very few"
> Page6 "which is usually best-efforts" should be "which is usually
> best- effort"
> Page6 "one of reasons" should be "one of the reasons"
> 
> There are a number of other minor nits like that. I'll try to forward 
> you some off the list.
> 
> simple question:
> 
> What about responsibility for inter domain links? Would that not be a 
> function of the MCDF? Don't see it discussed.
> 
> Peter
> 
> > -----Original Message-----
> > From: Daniele Ceccarelli [mailto:[e-mail]]
> > Sent: Wednesday, December 17, 2014 11:43 AM
> > To: AshwoodsmithPeter; Igor Bryskin; [e-mail]
> > Subject: RE: [Actn] New Version Notification for
> > draft-ceccarelli-actn- framework-05.txt
> >
> > Hi Peter,
> >
> > Thanks for jumping in. I definitely agree with you and Igor 
> > depending on the cases. I think my last reply to Igor should address 
> > your concerns.
> >
> > BR
> > Daniele
> >
> > > -----Original Message-----
> > > From: AshwoodsmithPeter [mailto:[e-mail]]
> > > Sent: mercoledì 17 dicembre 2014 16:48
> > > To: Igor Bryskin; Daniele Ceccarelli; [e-mail]
> > > Subject: RE: [Actn] New Version Notification for
> > > draft-ceccarelli-actn- framework-05.txt
> > >
> > > There is a definite elegance to what Igor suggests and experience
> > with
> > > recursion definitely teaches that elegance is associated with
> > correctness.
> > >
> > > Peter
> > >
> > > > -----Original Message-----
> > > > From: ACTN [mailto:[e-mail]] On Behalf Of Igor 
> > > > Bryskin
> > > > Sent: Wednesday, December 17, 2014 9:08 AM
> > > > To: Daniele Ceccarelli; [e-mail]
> > > > Subject: Re: [Actn] New Version Notification for
> > > > draft-ceccarelli-actn- framework-05.txt
> > > >
> > > > Hi Daniele,
> > > >
> > > > >> I'm not too "religious" about the naming but I think a 
> > > > >> distinction
> > > > is useful.
> > > >
> > > > The point is that if we say that MDSC and PSC are the same, we 
> > > > will have one component less in the framework, and the lesser we 
> > > > have components the easier it is to make the framework recursive.
> > > >
> > > > >> One further thing that in my opinion is only relevant to the
> > MDSC
> > > > >> is
> > > > the management of non-connectivity services, i.e. the ones that 
> > > > are called " Network Function Virtualization Services". I am
> think
> > > > of a customer requesting for a virtual machine and a given 
> > > > amount of storage. The PNC is the one in charge of providing
> connectivity
> > > > towards the data-center but other things like VM redundancy, VM 
> > > > mobility between DCs, storage location and services like that go 
> > > > beyond the scope of the PNC, or to better say: I would split so 
> > > > different functionalities into different entities.
> > > >
> > > > I respectively disagree with this. IMHO the recursive nature of 
> > > > the interface between service client and service provider 
> > > > applies to
> > all
> > > > the provided services: abstract topology, connectivity, network 
> > > > function virtualization, etc. I hope you agree that if a client 
> > > > requests a VNF, the latter does not have to be mapped directly 
> > > > on a physical NF, rather, it could be further requested from a 
> > > > subordinate provider.
> > > > To put it simply ACTN framework could be described as a stack of 
> > > > MDSCs with the same interface (supported by the same set of
> > > > models) between any two adjacent MDSCs in the stack.
> > > >
> > > > Cheers,
> > > > Igor
> > > >
> > > > -----Original Message-----
> > > > From: Daniele Ceccarelli
> > > > [mailto:[e-mail]]
> > > > Sent: Wednesday, December 17, 2014 5:51 AM
> > > > To: Igor Bryskin; [e-mail]
> > > > Subject: RE: [Actn] New Version Notification for
> > > > draft-ceccarelli-actn- framework-05.txt
> > > >
> > > > Hi Igor,
> > > >
> > > > Thanks a lot for the review.
> > > > Regarding your comments please see in line.
> > > >
> > > > Cheers,
> > > > Daniele
> > > >
> > > > > -----Original Message-----
> > > > > From: Igor Bryskin [mailto:[e-mail]]
> > > > > Sent: lunedì 15 dicembre 2014 20:50
> > > > > To: Daniele Ceccarelli; [e-mail]
> > > > > Subject: RE: [Actn] New Version Notification for
> > > > > draft-ceccarelli-actn- framework-05.txt
> > > > >
> > > > > Hi Daniele,
> > > > >
> > > > > I have a couple of comments:
> > > > > 1. I don't think that one of explicit Adrian's requests - the 
> > > > > recursive nature of the ACTN architecture with corresponding
> use
> > > > cases
> > > > > (when a client of a transport network serves as a transport 
> > > > > provider for its own clients, and when the transport network 
> > > > > provider makes
> > > > use
> > > > > of its own providers0 - is not properly elaborated  in the
> > document.
> > > > I
> > > > > think a dedicated section is necessary.
> > > >
> > > > I tried to capture in figure 3 the PNC recursiveness but the
> ASCII
> > > > in this case didn't help much. Maybe a dedicated section with
> some
> > > > text and a focused figure would be helpful. If you could provide 
> > > > it I would be happy to include it.
> > > >
> > > > >
> > > > > 2. On Figure 4. It is shown that a PNC can make use of other 
> > > > > PNCs (e.g. one in the middle of the picture). I assume that
> said
> > > > > PNC can talk to more than one subordinate PNCs. If this is the 
> > > > > case, it must perform multi-domain coordination just like MDSC.
> > > >
> > > > Correct. If you remember the colors in Sergio's presentation, 
> > > > there were functionalities associated to each controller. The
> > "multidomain
> > > > coordination" functionality is associated both to the PNC and 
> > > > the
> > MDSC.
> > > > This is explained at the beginning of section 3 (the 4 
> > > > functionalities are listed) and sections 3.1, 3.2, 3.3 state
> which
> > > > functionalities are present on each controller.
> > > >
> > > >   Furthermore, when MDSC performs such
> > > > > coordination for a given service, it is assumed that the 
> > > > > topology (nodes and
> > > > > links) the service is placed on may be abstract and could be 
> > > > > provided by underlying PNCs (which is correct); however, the 
> > > > > service termination points must be *under direct control* of 
> > > > > MDSC (I don't believe that service termination points could be 
> > > > > virtualized and provided by subordinate PNCs). In other words, 
> > > > > MDSC must physically control service termination points. The
> > point
> > > > > is that whether you
> > > > call
> > > > > it MDSC or VNC, I fail to see a difference between this
> *animal*
> > > > > and
> > > > PNC.
> > > > >
> > > >
> > > > I'm not too "religious" about the naming but I think a
> distinction
> > > > is useful. I think of the PNC as the entity which has the same
> > scope
> > > > of GMPLS, so only dealing with the "line interfaces" and not the 
> > > > "customer interfaces", which are need for the provisioning of 
> > > > services. In other word what IMHO is exported to "north" by the 
> > > > PNC is just links and nodes (real or abstracted) while the MDSC 
> > > > can
> > also
> > > > speak about services.
> > > > One further thing that in my opinion is only relevant to the 
> > > > MDSC
> > is
> > > > the management of non-connectivity services, i.e. the ones that 
> > > > are called " Network Function Virtualization Services". I am
> think
> > > > of a customer requesting for a virtual machine and a given 
> > > > amount of storage. The PNC is the one in charge of providing
> connectivity
> > > > towards the data-center but other things like VM redundancy, VM 
> > > > mobility between DCs, storage location and services like that go 
> > > > beyond the scope of the PNC, or to better say: I would split so 
> > > > different functionalities into different entities.
> > > >
> > > > That said I think no one would argue if we add a statement
> saying:
> > > > Both PNC and MSDC could be implemented into a single SDN
> > controller.
> > > >
> > > > > Cheers,
> > > > > Igor
> > > > >
> > > > > -----Original Message-----
> > > > > From: ACTN [mailto:[e-mail]] On Behalf Of Daniele 
> > > > > Ceccarelli
> > > > > Sent: Monday, December 15, 2014 6:37 AM
> > > > > To: [e-mail]
> > > > > Subject: [Actn] New Version Notification for
> > > > > draft-ceccarelli-actn- framework-05.txt
> > > > >
> > > > > Hi all,
> > > > >
> > > > > We just posted a new version of the framework document. Please 
> > > > > have a look at it as there are many major changes.
> > > > > A short recap:
> > > > >
> > > > > - 4 functionalities have been defined for the different
> > controller.
> > > > > The new functionality includes the management of services (i.e.
> > > > > we're no longer speaking just about links and nodes but also
> > about
> > > > services)
> > > > > - 2 types of services have been defined.
> > > > > 	- Service-aware Connectivity Services: all the network
> > service
> > > > > operations used to provide connectivity between customer 
> > > > > end-points
> > > > e.g.
> > > > > VPNs
> > > > > 	- Network Function Virtualization Services: between
> > customers'
> > > > > premises and service provider premises and are provided mostly 
> > > > > by cloud providers or content delivery providers. We are 
> > > > > speaking about storage, virtual machines, VM mobility and so
> on.
> > > > > - VNC renamed into MDSC and a mapping between controller and 
> > > > > functionalities has been provided
> > > > > - Applicability section added
> > > > > - Summary of the use cases added
> > > > > - A mapping among use cases and what is (in authors opinion at
> > > > > least) a new work in ACTN scope is provided.
> > > > >
> > > > > Comments are appreciated.
> > > > >
> > > > > Many thanks
> > > > > The authors.
> > > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail] [mailto:internet-
> [e-mail]]
> > > > > Sent: lunedì 15 dicembre 2014 12:30
> > > > > To: Daniele Ceccarelli; Luyuan Fang; Young Lee; Daniel King; 
> > > > > Luyuan Fang; Daniele Ceccarelli; Daniel King; Young Lee; Diego
> R.
> > > > > Lopez; Diego Lopez; Sergio Belotti; Sergio Belotti
> > > > > Subject: New Version Notification for 
> > > > > draft-ceccarelli-actn-framework-05.txt
> > > > >
> > > > >
> > > > > A new version of I-D, draft-ceccarelli-actn-framework-05.txt
> > > > > has been successfully submitted by Daniele Ceccarelli and
> posted
> > > > > to the IETF repository.
> > > > >
> > > > > Name:		draft-ceccarelli-actn-framework
> > > > > Revision:	05
> > > > > Title:		Framework for Abstraction and Control of
> > Transport
> > > > > Networks
> > > > > Document date:	2014-12-15
> > > > > Group:		Individual Submission
> > > > > Pages:		35
> > > > > URL:            http://www.ietf.org/internet-drafts/draft-
> > ceccarelli-
> > > > actn-
> > > > > framework-05.txt
> > > > > Status:         https://datatracker.ietf.org/doc/draft-
> > ceccarelli-
> > > > actn-
> > > > > framework/
> > > > > Htmlized:       http://tools.ietf.org/html/draft-ceccarelli-
> actn-
> > > > framework-05
> > > > > Diff:           http://www.ietf.org/rfcdiff?url2=draft-
> > ceccarelli-
> > > > actn-framework-
> > > > > 05
> > > > >
> > > > > Abstract:
> > > > >    This draft provides a framework for abstraction and control
> of
> > > > >    transport networks.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 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.
> > > > >
> > > > > The IETF Secretariat
> > > > >
> > > > > _______________________________________________
> > > > > ACTN mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/actn
> > > > _______________________________________________
> > > > ACTN mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/actn
> _______________________________________________
> ACTN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/actn
_______________________________________________
ACTN mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/actn
_______________________________________________
ACTN mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/actn