Re: [Actn] Status and plans for ACTN

["Adrian Farrel" <[e-mail]>]

Thanks for the discussion, Fatai.

> Q: What is entirely new and needs the focus of a WG?
> 
> [Fatai]: How to provide the Virtual Network to the customers respectively is
> totally new for the IETF community, even though some of the work like Lx VPN
> (especially L1VPN) had been defined/discussed in IETF. I think  the Virtual
> Network in the scope of ACTN is clearly beyond of L1 VPN, which provides L1
VPN
> services/connections between CE devices. Therefore, from the functionality
> perspective, I see some new things. firstly, I think the L1 VPN (concluded) +
L0
> VPN could fit part of the *new* work. Secondly, how to return the Virtual
> Network to the customer (e.g, creation and query) and how to manage the
> Virtual Network (e.g., deletion, modification) is totally new, which needs
> policy/business constraints. Thirdly, how to provision the service/connection
over
> the Virtual Network might be different from the provisioning connection over
the
> physical networks. Fourthly, data Model for the Virtual Network might be
> another new thing. More new things might come later, :-)

I think we need to be pretty careful in our definition of virtual network to
avoid overlapping with work that (for example) BESS might do in terms of
configuring and enabling L3VPNs.

> Q: What is new but likely to be worked on in other WGs may be needing review
> and guidance from an ACTN WG?
> 
> [Fatai]: Setup the *Virtual* connection over the Virtual Network is new, but
> could be defined in CCAMP/TEAS by extending RSVP-TE protocols or any other
> WGs including ACTN itself by other means (e.g., centralized provisioning).
> Something new related to routing might be worked in OSPF WG.

Interesting. I see "set up" as different from "request/provision". 
The difference is that for "set up" one might use control plane signaling
(RSVP-TE) or centralized provisioning (classic SDN). But for "request/provision"
of  connectivity we are missing a north-south request. The first is modifying
existing work (see next question); the second is new work (this question).
However, in both cases I think you are right that this falls into
TEAS/CCAMP/MPLS.

> Q: What is a delta on work done in other WGs that needs cooperative
> development?
> 
> [Fatai]: I don't see clear boundary between this question and the above
question
> (the second one). Clarification would be much appreciated.

I hope the previous answer helps.
The distinction is illustrated by:
- Make modifications to existing protocols (such as extensions to PCEP)
  is a delta to work already done in other WGs.
- Create something new (such as a YANG model for the TED) is new work
   that is in scope for an existing working group
- Create an extension to a YANG model for a specific purpose might 
  would be done in cooperation with the WG that owns the YANG model.
  
> Q: What already exists but needs an applicability statement to demonstrate its
> use?
> 
> [Fatai]:No answer, :-)

I think this might follow from a closer understanding of the interface
requirements. It may be that we write the first version of an applicability
statement that says "Do this with protocol foo; do that with extensions to
protocol bar (pending work); do the other thing with a new protocol (pending
work)". Then, as we advance we will be able to update the applicability
statement to point to real work.

Cheers,
Adrian
 
> Hello again,
> 
> As promised here are some more thoughts on the progress of ACTN.
> 
> I had a call today with the BoF chairs: Sergio and Dhruv were also there. We
> discussed the details of the interfaces between the ACTN components a bit more
> because my main thrust is to understand what work needs doing in a protocol
> sense.
> 
> My message is that I recognise the energy and use cases behind ACTN, but I do
> not want to charter a working group to work on use cases and requirements.
> From where I sit, that would be a huge waste of time and effort. We already
> understand the use cases, so while it would be just fine to continue to work
on
> them, they are no longer a hurdle for forming a WG or for developing
solutions.
> What is more, the requirements work can be developed quickly and efficiently
by
> a small team and then discussed and reviewed on this mailing list.
> 
> The intention, therefore, is to take the current framework draft and:
> - refine it to make the architecture clearer
>    - there is at least the question of recursion to be dealt with
> - expand on exactly what the client is asking for
>    - is it "just" abstract topology and connectivity, or is it also
>       related to "services"?
> - add a lot more detail to the description of the functional interfaces
>     - what are the primitives?
>     - what i the information carried on the primitives?
> 
> Young, Daniele, Sergio, and Dhruv already have some of this material in slides
and
> in notes as well as in their heads. So I'm hoping that it will not be a huge
effort for
> them to start to share this on the list and to add to the I-D.
> 
> I'm hoping that this will serve to make it much clearer what work is actually
> involved in delivering ACTN. What is entirely new and needs the focus of a WG?
> What is new but likely to be worked on in other WGs may be needing review and
> guidance from an ACTN WG? What is a delta on work done in other WGs that
> needs cooperative development? What already exists but needs an applicability
> statement to demonstrate its use?
> 
> The answers to these questions will help us understand the value of a new
> working group, and will form the basis of the deliverables and work items if
one is
> chartered.
> 
> Young and Daniele have promised to try to bring their thoughts to this list in
the
> form of emails and a revised I-D. I really hope that we can build on the
energy
> that was in the room in Honolulu by having active discussion of the issues
they
> raise and by getting detailed and constructive reviews (e.g. suggest
> text!) of the drafts they post.
> 
> Thanks,
> Adrian
> 
> _______________________________________________
> ACTN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/actn