[Teas] WG Last Call: draft-ietf-teas-pce-native-ip-06
Aijun Wang <wangaijun@tsinghua.org.cn> Mon, 01 June 2020 01:21 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 0D0013A0A04 for <teas@ietfa.amsl.com>; Sun, 31 May 2020 18:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Th7yjdMs-F9Q for <teas@ietfa.amsl.com>; Sun, 31 May 2020 18:21:16 -0700 (PDT)
Received: from m176115.mail.qiye.163.com (m176115.mail.qiye.163.com [59.111.176.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBDF03A086D for <teas@ietf.org>; Sun, 31 May 2020 18:21:15 -0700 (PDT)
Received: from WangajPC (unknown [219.142.69.77]) by m176115.mail.qiye.163.com (Hmail) with ESMTPA id 3AF21664BAA; Mon, 1 Jun 2020 09:21:08 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: 'Dhruv Dhody' <dhruv.ietf@gmail.com>, 'Lou Berger' <lberger@labn.net>
Cc: 'TEAS WG' <teas@ietf.org>
Date: Mon, 01 Jun 2020 09:21:07 +0800
Message-ID: <000b01d637b2$ed5fe740$c81fb5c0$@org.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Content-Language: zh-cn
Thread-Index: AdY1t0nziOM037btTIOehjqYrl49XgAhnPwAAFwkVIA=
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZT1VCTklLS0tKT0pKT0hDWVdZKFlBSk xLS0o3V1ktWUFJV1kPCRoVCBIfWUFZLRYpTzgcOBVDHAw#LDUpHj8sNhc6OlZWVUpLSihJWVdZCQ 4XHghZQVk1NCk2OjckKS43PllXWRYaDxIVHRRZQVk0MFkG
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Kyo6CQw6Cjg4FRgyPxJRMhdI CR0wCxRVSlVKTkJLQkxPT0xITkNOVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxMWVdZCAFZQUpKSUxNNwY+
X-HM-Tid: 0a726d77d0ff9373kuws3af21664baa
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/amVjzTSCqWSP1H2GU1DTQqkLKLw>
Subject: [Teas] WG Last Call: draft-ietf-teas-pce-native-ip-06
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: Mon, 01 Jun 2020 01:21:19 -0000
Hi, Dhruv: We have updated the draft according your comments, please view it again and wish to get your comments on the update. For the document track, we want to ask chair to change it from "Experimental" to "Standard". The reasons for this change are the followings: 1. Central control component is necessary for various networks/technologies to accomplish the E2E QoS assurance, such as MPLS, SRv6. and Native IP network. 2. Native IP network deployment is the trending in near future, alongside the emerge of Cloud Overlay solution. 3. It needs to standardize the process and PCEP protocol extension to assure the interoperability. Welcome also the comments from other experts. Please see the detail responses below inline. Best Regards. Aijun Wang China Telecom -----邮件原件----- 发件人: teas-bounces@ietf.org [mailto:teas-bounces@ietf.org] 代表 Dhruv Dhody 发送时间: 2020年5月29日 20:46 收件人: Lou Berger 抄送: TEAS WG 主题: Re: [Teas] WG Last Call: draft-ietf-teas-pce-native-ip-06 Hi WG, Authors, As an experimental framework based on RFC 8735, I am fine with publication of this document. But I do have comments and thoughts on what is missing in this I-D. Request authors and shepherd to consider them before we ship this out of the WG. (1) I find the term "Dual/Multi-" used throughout in this document to be bit weird. Well 'multi-' includes 'dual-' :) 【WAJ】Accepted. (2) We need to add some text that describes the experimental nature of this work. Something in line with The procedures described in this document are experimental. The experiment is intended to enable research for the usage of PCE in native IP scenarios. For this purpose, this document describe the CCDR framework and the PCEP extension is specified in [I-D.ietf-pce-pcep-extension-native-ip]. 【WAJ】We have asked the TEAS chair to change the track to "Standard". Wait for the response from the chair. The reasons for this are stated at above. (3) Section 1 We should be clear on where are these requirements coming from. Can we say that they are based on the scenarios listed in RFC 8735(?), so it does not read out of place. More importantly, the list is a mix of technology choices, deployment limitations, and abstract philosophy; calling them requirement may be a stretch. Further, 【WAJ】These requirements are proposed based on the scenarios described in RFC8735. When we want to adopt or develop some technologies, we should evaluation them in various aspects. o No complex Multiprotocol Label Switching (MPLS) signaling procedures. Why signaling alone? Isn't data-plane as native IP, one of the key requirements? 【WAJ】For MPLS to achieve the Traffic Engineering aim, the complex part is the signaling, network node must preserve the machine state during signaling. The data plane itself is straightforward. o End to End traffic assurance, determined Quality of Service (QoS) behavior. Should we specify that this in the control plane? 【WAJ】This is the ultimate aim the technology selection and design aim of the control plane. o Flexible deployment and automation control. IMHO too generic (and marketing). 【WAJ】Just want to express the solution should adjust the path dynamicly and not the static planning. Also, please describe CCDR in the Introduction. Jumping directly into example in section 4 is not right. 【WAJ】:Add the following description to explain the CCDR: " It depends on the central control (PCE) element to compute the optimal path for selected traffic, and utilizes the dynamic routing behavior of traditional IGP/BGP protocols to forward such traffic. " (4) If you don't use RFC 2119 keywords, then remove section 2. 【WAJ】Accepted. (5) Section 4, - you should be explicit that IP11, IP12 are IP prefix. 【WAJ】: Done, change also the name from IP to PF respectively. - you need to describe the term "explicit peer routes"? How is it different from a static route? 【WAJ】:Want to emphasize that the route is to BGP peer(the loopback address on border router), not to the final destination(PF11/PF12/PF21/PF22) - I think we should say that section 4 is only for illustrative Purpose 【WAJ】:The simple topology is just for showing the key points of the CCDR solution. - I am not sure why the description is in terms of address pairs (IP11, IP21) and (IP12, IP22) - what happens if one sends traffic from IP11 to IP22? I guess the forwarding would be based on destination IP22 and the traffic would be sent to the link associated with it? Doesn't it make more sense to describe things in terms of IP prefix? 【WAJ】:You are right. The forwarding is based on destination address. Use the pair just want to show normally the application requires bi-direction assurance. Actually, the two directions can be deployed separately, same as the MPLS LSP. (6) Section 6, you have - It is almost impossible to provide an End-to-End (E2E) path with latency, jitter, packet loss constraints to meet the above requirements in large scale IP-based network via the distributed routing protocol... Well flex-algo to some extent could do this. So maybe reword this... 【WAJ】The deployment of Flex-algo requires the allocation of links into different groups in advance. We think it will lead to the inefficiently usage of physical links. Also, consider avoiding using term flow and focus on just prefix. 【WAJ】Done, Changed the "flow" to "Prefix Set" (7) Section 7, Add some text on - - the loopback address used for the multi-BGP session. Do they exist at edge routers/RR already and PCE selects them? 【WAJ】 Yes. The loopback address should be planned in advance and be distributed in the domain. Has added the sentence to describe this. - how does PCE learn the prefix and QoS requirement 【WAJ】Via the Northbound interface of SDN Controller/PCE. Redraw the graph to reflect this. (8) Section 9.2, If one node on the optimal path is failed, the priority traffic will fall over to the best-effort forwarding path. One can even design several assurance paths to load balance/hot-standby the priority traffic to meet the path failure situation, as done in MPLS Fast Reroute (FRR). Not sure how MPLS FRR is applicable here (perhaps IP FRR for static routes)? 【WAJ】Delete the analogy to avoid possible misunderstanding. (9) Section 10, The PCE should have the capability to calculate the loop-free E2E path upon the status of network condition and the service requirements in real time. This is true for any PCE, don't think it belongs in Security consideration. 【WAJ】Change the sentence as " A PCE assures calculations of E2E path upon the status of network condition and the service requirements in real time." This section needs to be improved as one can use PCEP to create bogus BGP sessions and we need to consider what would be impact on that. Further what would be the impact of incorrect prefix, can this be used to misdirect traffic. 【WAJ】Currently, we assumed the interaction between PCE and the underlying devices is secured, via the PCEPS, as described in RFC8253. The PCE and their communication is authorized/authenticated. It seems impossible to encounter bogus bgp seesion and incorrect prefix? (10) Other considerations - Few things that are missing - - PCE and PCEP considerations - Stateful nature of PCE, path state at the PCE, synchronization of the state etc 【WAJ】These depend on the existing mechanism. No special requirements. Would you like to provide some text or thoughts? - Multi-domain case - as that is listed as a key benefit of CCDR. 【WAJ】Add sentence at the "Scalability" part: "For multiple domain deployment, the PCE need only control the edge router to build multiple eBGP sessions, all other procedures are the same that in one domain." - Impact of dynamic BGP session created based on CCDR. 【WAJ】No extra impact. Similar that you build multiple BGP sessions via configuration. - Impact of "explicit peer routes" and their interaction with other routes. 【WAJ】Add some sentence at section "PCEP extension for key parameter" as below: "The explicit route created by PCE has the higher priority than the route information created by other protocols, including the route manually configured All above dynamically created states (BGP sessions, Prefix advertised prefix, Explict route) will be cleared once the connection between the PCE and network devices is interrupted. These parts will be considered in more detail in protocol extension draft. - Document does not mention removal and modification at all 【WAJ】:Depends on the existing LSP removal/modification mechanism. If necessary, will expand it in the protocol extension draft. - Comparison to other techniques is distributed in various section, maybe collect them in appendix 【WAJ】:try to focus on the "Deployment Consideration" part. (11) Nits - I suggest following the abbreviation guideline as per https://www.rfc-editor.org/materials/abbrev.expansion.txt; I see some well-known terms (BGP, PCE) expanded. Look for (*) in the link. 【WAJ】Has removed the well-known abbreviation expansion. If necessary, expand it later again. - Remove "Draft" in section 1 - "Draft [RFC8735] describes..." - Section 1, s/differentiation/different/ - Not a good idea to have Lo0, Lo1 on both R1 and R2 - perhaps Lo11, Lo12 and Lo21, Lo22? - Add reference for BGP stuff like RR 【WAJ】Done Thanks! Dhruv _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas
- [Teas] WG Last Call: draft-ietf-teas-pce-native-i… Aijun Wang
- Re: [Teas] WG Last Call: draft-ietf-teas-pce-nati… Joel M. Halpern
- Re: [Teas] WG Last Call: draft-ietf-teas-pce-nati… Dhruv Dhody
- [Teas] 答复: WG Last Call: draft-ietf-teas-pce-nati… Aijun Wang
- Re: [Teas] WG Last Call: draft-ietf-teas-pce-nati… Dhruv Dhody