Re: [OPSAWG] a new version of the automatic attachment drafts

[Zhoutianran <[e-mail]>]

Hi Dan,

Thank you for the reply. That makes me clear now.
I was once interested on the cloud VPN solution. The customer provisioned virtual private cloud can automatically joins(attach to) the existing enterprise VPN.
I think the scenario also fit in this framework. It might be one use case considered in your draft.

Regards,
Tianran

From: Romascanu, Dan (Dan) [mailto:[e-mail]]
Sent: Monday, July 11, 2016 5:20 PM
To: Zhoutianran; [e-mail]
Cc: Unbehagen Jr, Paul E (Paul)
Subject: RE: a new version of the automatic attachment drafts

Hi Tianran,

Thank you for the reading and for the comments.

Your observation is very correct and it relates to something that we failed to explain in enough details in the I-D. The AA controller in the diagram should not be regarded as a 'super-controller' across administrative domains, but rather as a policy function that applies to the network and may be instantiated in different ways. The 'vertical' data model (6) in the diagram does not carry the same information to AACs and AASs. There are two possible scenarios here:


1.      The AA controller connects only to the AAS and configures the mapping policies on the network devices. Clients are configured mainly by the horizontal interaction - this will be true also in most of the IoT scenarios

2.      Both AAS and AACs connect to the AA controller function. The clients get authentication and local security and local services information from the controller (what services are available, how you configure to them). Servers perform same functionality as in #1. The implementation of the controller may be distributed, possibly with an 'orchestration' function in-between. This fits for example the BYOD use cases.

I hope this clarifies both comments. I will make one slide to address the comments at the meeting, and include a more detailed description for the next round of I-Ds.

Regards,

Dan


From: Zhoutianran [mailto:[e-mail]]
Sent: Friday, July 8, 2016 5:29 AM
To: Romascanu, Dan (Dan); [e-mail]<mailto:[e-mail]>
Subject: RE: a new version of the automatic attachment drafts

Hi Dan,

I am reading the framework draft. Here are some initial comments:

1. In figure 1, the AA controller has connection to both AA client and AA server. I think it's not practical in many cases. AAC and AAS, IMHO, are usually in different administrative domains. For example, AAC installed on a CE, and the AAS installed on the PE. Usually, CE and PE are controlled by different domain controllers. It's hard to deploy a super controller for CE and PE. Another example is, as you showed, the IoT. It's not practical to let all the end devices connect to the AA controller.
Here, what scenario did you consider for this framework?
The suggestion, if I am right, is to have the AA controller only connect to the AAS. AAC can pull additional information from the path: AA controller->AAS->AAC.

2. If both AAC and AAS connect to the AA controller, that means the AAC and AAS can be synchronized and configured by the management plane. So I guess some of the control plane function between AAC and AAS can be reduced.


Regards,
Tianran

From: OPSAWG [mailto:[e-mail]] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, June 30, 2016 1:58 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [OPSAWG] a new version of the automatic attachment drafts

Hi,

I have submitted two new Internet-Draft that describe the automatic attachment functionality:

https://datatracker.ietf.org/doc/draft-romascanu-opsawg-auto-attach-framework/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dromascanu-2Dopsawg-2Dauto-2Dattach-2Dframework_&d=CwMFAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=5FKNb8y64EQaQBIAzZciKWnxOznvGh_XbikFD3KVv24&s=cIIUowtv3UQgUn-Qtt5JuJxjJuRAd3TyrJTLmoAiGmw&e=>
https://datatracker.ietf.org/doc/draft-romascanu-opsawg-auto-attach-lldp/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dromascanu-2Dopsawg-2Dauto-2Dattach-2Dlldp_&d=CwMFAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=5FKNb8y64EQaQBIAzZciKWnxOznvGh_XbikFD3KVv24&s=kfxeNRG9cQnc_CpNcRKkee83AoXcactq6q8ii6Itgs8&e=>

Principal changes:

- addressing the comments received at IETF 95  we split the generic protocol-independent framework that describes the discovery and service mapping mechanism in a separate I-D

- we clarified terminology and re-drawn the principal building blocks
- we connected the discovery and authentication mechanism with the MUD proposal

Questions and comments are welcome.

Thanks and Regards,

Dan