IETF Logo Mail Archive

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

Zhoutianran <zhoutianran@huawei.com> Fri, 08 July 2016 02:29 UTC

Return-Path: <zhoutianran@huawei.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA18112D775 for <opsawg@ietfa.amsl.com>; Thu, 7 Jul 2016 19:29:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.646
X-Spam-Level:
X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyU_Ym4Di59b for <opsawg@ietfa.amsl.com>; Thu, 7 Jul 2016 19:29:16 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0762F12D645 for <opsawg@ietf.org>; Thu, 7 Jul 2016 19:29:14 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CSF31460; Fri, 08 Jul 2016 02:29:12 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 8 Jul 2016 03:29:11 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Fri, 8 Jul 2016 10:29:07 +0800
From: Zhoutianran <zhoutianran@huawei.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: a new version of the automatic attachment drafts
Thread-Index: AdHSL7Tm7cjwLHTRRWWWYvwrin0y4AGjPzDA
Date: Fri, 08 Jul 2016 02:29:07 +0000
Message-ID: <BBA82579FD347748BEADC4C445EA0F2183BFADBD@NKGEML515-MBX.china.huawei.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA75220B90@AZ-FFEXMB04.global.avaya.com>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA75220B90@AZ-FFEXMB04.global.avaya.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.156.116]
Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F2183BFADBDNKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.577F0FF9.0006, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: e26fbe729c3486dbe037792d5a0b308b
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/jf1d2HImrDVwr_B6O_kQj3NTZSY>
Subject: Re: [OPSAWG] a new version of the automatic attachment drafts
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jul 2016 02:29:23 -0000

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:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, June 30, 2016 1:58 AM
To: opsawg@ietf.org
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://datatracker.ietf.org/doc/draft-romascanu-opsawg-auto-attach-lldp/

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

v2.46.0 | Report a Bug | By Email | System Status