[Actn] ***SPAM*** 7.446 (5) RE: Status and plans for ACTN

[이광국(통합전달망팀) <[e-mail]>]

Hi.

This is my opinion about the question "what is entirely new and needs the focus of a WG".

As we mentioned in our use-case (ACTN use-case for on-demand E2E connectivity Services in Multiple Vendor Domain Transport Networks), the border area is vulnerable points when multi-domains are constructed by multi-vendor solutions. One might think single-vendor deployment is the best solution but operator’s domains are not easily deployed by such kinds of approach. Nobody cannot touch the border area, so generally operators have to develop some integration functions in their own NMS to control whole area. But, whenever new devices are deployed, this is quite time-consuming and hurdle points to rapidly make new business model. It results in sticking to the same vendor (vendor-lock-in) from operators.

Most of operators recognize that the current network paradigm is slightly shifted from distributed networking to centralized networking by the SDN/NFV tornado. But, actually this is not a brand-new approach since original transport networks also have such kinds of centralized management approaches. If so, what operators expect from ACTN working group?

As we know, several standard organizations and working groups are formed lately and make an effort for the standardization. But my concern is that although many working groups are created, their works are somewhat overlapped and they do not even talk to each other. There are not enough interactions amongst them.

Such fragmented standardization might also generate SILOED-SDN architectures for operator networks. We agree that anybody (operators, vendors) does not want such results. The reason I joined this group is that this group aims at the harmonization of such fragmented islands including non-SDN domains in IETF. Technically, ACTN approach to control border areas as well as whole transport networks by its centralized management mechanisms is able to solve several issues in terms of the end-to-end connectivities and the support of virtualized networks. So, I hope this group be organized and then build a foundation to interact with all network domains by the general information and data model.

best regards,
Kwang-koog Lee

-----Original Message-----
From: ACTN [mailto:[e-mail]] On Behalf Of Adrian Farrel
Sent: Monday, December 01, 2014 9:53 PM
To: 'Fatai Zhang'; [e-mail]
Cc: [e-mail]
Subject: Re: [Actn] Status and plans for ACTN

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

_______________________________________________
ACTN mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/actn


이 메일은 지정된 수취인만을 위해 작성되었으며, 중요한 정보나 저작권을 포함하고 있을 수 있습니다. 어떠한 권한 없이, 본 문서에 포함된 정보의 전부 또는 일부를 무단으로 제3자에게 공개, 배포, 복사 또는 사용하는 것을 엄격히 금지합니다. 만약, 본 메일이 잘못 전송된 경우, 발신인 또는 당사에 알려주시고, 본 메일을 즉시 삭제하여 주시기 바랍니다.
This E-mail may contain confidential information and/or copyright material. This email is intended for the use of the addressee only. If you receive this email by mistake, please either delete it without reproducing, distributing or retaining copies thereof or notify the sender immediately.