IETF Logo Mail Archive

Re: [Teas] Last Call: <draft-ietf-teas-native-ip-scenarios-08.txt> (Scenarios and Simulation Results of PCE in Native IP Network) to Informational RFC

Aijun Wang <wangaijun@tsinghua.org.cn> Sat, 28 September 2019 13:02 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97EA120826; Sat, 28 Sep 2019 06:02:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 1r6H3_th0Kwq; Sat, 28 Sep 2019 06:02:33 -0700 (PDT)
Received: from m176115.mail.qiye.163.com (m176115.mail.qiye.163.com [59.111.176.115]) by ietfa.amsl.com (Postfix) with ESMTP id AD8EA120A54; Sat, 28 Sep 2019 06:02:31 -0700 (PDT)
Received: from [240.0.0.1] (unknown [3.9.186.152]) by m176115.mail.qiye.163.com (Hmail) with ESMTPA id CEFBC66255D; Sat, 28 Sep 2019 21:02:26 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-AD5E8881-F5B7-445B-BC71-4FAF26177676"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Sat, 28 Sep 2019 21:02:20 +0800
Message-Id: <556B5AC9-3EE6-4528-BAFE-3ECBE52FB118@tsinghua.org.cn>
References: <6.2.5.6.2.20190928043919.0e4ada60@elandnews.com>
Cc: teas@ietf.org, teas-chairs@ietf.org
In-Reply-To: <6.2.5.6.2.20190928043919.0e4ada60@elandnews.com>
To: S Moonesamy <sm+ietf@elandsys.com>
X-Mailer: iPhone Mail (17A577)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZSVVKTkJCQkJDT0xPSklKSllXWShZQU pMS0tKN1dZLVlBSVdZCQ4XHghZQVk1NCk2OjckKS43PlkG
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6PQg6MDo5DDlMHVERKhUREAkM VgowC0NVSlVKTk1CTUxOTE5LQ0hPVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlIVUJVSkNNVUpOSVlXWQgBWUFDSUtONwY+
X-HM-Tid: 0a6d77f71e219373kuwscefbc66255d
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/80huAyxOFUb-wRvDAXuAvqd-IDs>
Subject: Re: [Teas] Last Call: <draft-ietf-teas-native-ip-scenarios-08.txt> (Scenarios and Simulation Results of PCE in Native IP Network) to Informational RFC
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Sep 2019 13:02:44 -0000

Hi, S Moonesamy:

2. Specification of terminology, architecture, and protocol
requirements for abstraction and distribution of TE
information between interconnected TE domains/layers.

And, would you like to give other comments for the document? We just want to provide some useful information for the community. The community is composited of members from operators, vendors and researchers.

The draft just gives the scenarios that the operator encounters in real situations. Shouldn’t we design the technologies/solution towards the application’s requirements?

Aijun Wang
China Telecom

> On Sep 28, 2019, at 19:47, S Moonesamy <sm+ietf@elandsys.com> wrote:
> 
> Hi Aijun,
> At 02:48 AM 28-09-2019, Aijun Wang wrote:
>> Together with the solutions draft, I think they are fit to the deliverables described in the charter of TEAS WG.
> 
> Could you or another WG participant else please explain under which point in the WG Charter does the draft fit in?
> 
>> And actually, the operator's network is composed by the devices from vendors, and the algorithm may be from the university. Isn't such cooperation the direction of operator?
> 
> I am not arguing against such cooperation as cooperation is useful.  I would expect an operator or university to point out the pros and cons or else the document may sound too good to be true.  Furthermore, it can be useful to other operators if they are the intended audience.
> 
> Regards,
> S. Moonesamy 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas

v2.23.0 | Report a Bug | By Email