Re: [Teas] WG Last Call: draft-ietf-teas-pce-native-ip-06
"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 01 June 2020 01:58 UTC
Return-Path: <jmh@joelhalpern.com>
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 8A5173A0A94 for <teas@ietfa.amsl.com>; Sun, 31 May 2020 18:58:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 XxawzqBc7-Ss for <teas@ietfa.amsl.com>; Sun, 31 May 2020 18:58:25 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC9213A0A93 for <teas@ietf.org>; Sun, 31 May 2020 18:58:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 49Zyxs4z79z6GD8r; Sun, 31 May 2020 18:58:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1590976705; bh=u93QrbIztDp0XkQtdCBpnJazV77kskpefXk3At1+0v0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=X0LBUlyaFRtJdg557avo3RKGDcq7MkOuMKRiFaW4RvutAIDjOpoNBjGE3Dfa/9Rxf grboo5jgnjpJPp5QrG6hgDydjFujy00ALVAnK+G4ca5xzNiC0c/rGgrLYSFhBYRLoR wqKdVpSjH7zYtjoUadDjzP2Xthu0WCzSn5hqSxaM=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 49Zyxr0nL5z6G8rB; Sun, 31 May 2020 18:58:24 -0700 (PDT)
To: Aijun Wang <wangaijun@tsinghua.org.cn>, 'Dhruv Dhody' <dhruv.ietf@gmail.com>, 'Lou Berger' <lberger@labn.net>
Cc: 'TEAS WG' <teas@ietf.org>
References: <000b01d637b2$ed5fe740$c81fb5c0$@org.cn>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <b5096a11-5b97-3b63-6902-81aaa15c7f5b@joelhalpern.com>
Date: Sun, 31 May 2020 21:58:23 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <000b01d637b2$ed5fe740$c81fb5c0$@org.cn>
Content-Type: text/plain; charset="gbk"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/uoHTP-bUbMAMGPn7Qlz1eJzVQPc>
Subject: Re: [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:58:28 -0000
As an experimental RFC, I can't object to the content. Finding out if this approach works well is understandable. If it is proposed to make this a standard, without experimental deployment first, I would be very nervous. Yours, Joel On 5/31/2020 9:21 PM, Aijun Wang wrote: > 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 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