Re: [Teas] WG Last Call: draft-ietf-teas-pce-native-ip-06
Dhruv Dhody <dhruv.ietf@gmail.com> Fri, 29 May 2020 12:47 UTC
Return-Path: <dhruv.ietf@gmail.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 0197E3A07F7 for <teas@ietfa.amsl.com>; Fri, 29 May 2020 05:47:07 -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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vZQ2R-vlFt9a for <teas@ietfa.amsl.com>; Fri, 29 May 2020 05:47:05 -0700 (PDT)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544323A07ED for <teas@ietf.org>; Fri, 29 May 2020 05:46:44 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id q8so2143148iow.7 for <teas@ietf.org>; Fri, 29 May 2020 05:46:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aUnaRx3i7RAtRIIaYnGdKsl7kHKs3+abyG3z3H6Gkyo=; b=bTaE+dMRF4f5gmvOxy/pHNXG2+Tff8vggjitjm9tPUvnFvw2JFumJHdTk4DOrCCV/8 P2ie4CUuunO0Q6uLq/xB+YVX0yN0U3Hdyc4Y4orXYWvPCaIZEVCmvQEotclkvngfkCOZ VkIbFq8tIp0jqirGOlq+Tz3bd0LCH5BmzE0HCUOk2R0RZ6xdvNa3w3Lrtk8rhIz+jns3 FbN2fpr/PKeXemwKp/Rz+3H3MnjgAQK7Qx/elRlqAYlRpGDkGjZ+ynN40LfwwOdA3+A3 uYNL+sOjUMfG7kQvBCrq2ft6jvzBd3fWOvRYhX6ilFcVTNrtdu+qhyPbqrvaBIhJFWgL pnwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aUnaRx3i7RAtRIIaYnGdKsl7kHKs3+abyG3z3H6Gkyo=; b=ahd4AEVkrzumbSR3pEFwP5FgJyvnoGpSKsi4qUB4CRB+1YpcYL0kHy8fW+OfPhZigX rQC8U4g8pQCs5u9esn30a6RHkXek4tzlWrh/QQ6tHFhpQnerWzWjQ75rbT+0D1bEMeZG H/1QMeaJ4kzkT+5AlBnqmiDVSGph8i/qgndetkqbmmNQbe0JP1jLfvgdy2EXvV42JmLv abVsQLsfmxG/fRLbNQ1hbgmrZFG9KatTnWUKvw8e3F2ol3d0TxNhQM1AsUtnr0jpKeKo YqsksrtJrD7hJ/Mkv2dKgEcrTXtSQlkXQOoWDNqMLmMdQjvCgGgAkuV8/w2ZxusaosWz dPxQ==
X-Gm-Message-State: AOAM530/lfXhHk+s9sgCXFgtvMc/Iprykcg1oMGzDzLJ0J1vBFaVxv0S YqFKYAW2cUe5DlntIt8PifQw4jQFHWJZCQtihOYUZSr9v0o=
X-Google-Smtp-Source: ABdhPJyiOuc9MFyk+dBAHec0FjSTRwX78hqLSrH8pEZ5BDZr/LTOAFz+4s4I7VAhkG1zkEwzQSZr3uTk1smL+R3RMk0=
X-Received: by 2002:a05:6602:2ac9:: with SMTP id m9mr6392901iov.68.1590756403480; Fri, 29 May 2020 05:46:43 -0700 (PDT)
MIME-Version: 1.0
References: <147e62a8-91c6-12f4-4575-b3a3813e67bc@labn.net>
In-Reply-To: <147e62a8-91c6-12f4-4575-b3a3813e67bc@labn.net>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Fri, 29 May 2020 18:16:06 +0530
Message-ID: <CAB75xn5ht3QVVdpV_R8FHQWwjMKAUB=MLEOrGHb-5kSo8oKLow@mail.gmail.com>
To: Lou Berger <lberger@labn.net>
Cc: TEAS WG <teas@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/-C924rpZgdixHoqH__vpDiqd6Qc>
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: Fri, 29 May 2020 12:47:07 -0000
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-' :) (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]. (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, o No complex Multiprotocol Label Switching (MPLS) signaling procedures. Why signaling alone? Isn't data-plane as native IP, one of the key requirements? o End to End traffic assurance, determined Quality of Service (QoS) behavior. Should we specify that this in the control plane? o Flexible deployment and automation control. IMHO too generic (and marketing). Also, please describe CCDR in the Introduction. Jumping directly into example in section 4 is not right. (4) If you don't use RFC 2119 keywords, then remove section 2. (5) Section 4, - you should be explicit that IP11, IP12 are IP prefix. - you need to describe the term "explicit peer routes"? How is it different from a static route? - I think we should say that section 4 is only for illustrative purpose - 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? (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... Also, consider avoiding using term flow and focus on just prefix. (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? - how does PCE learn the prefix and QoS requirement (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)? (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. 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. (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 - Multi-domain case - as that is listed as a key benefit of CCDR. - Impact of dynamic BGP session created based on CCDR. - Impact of "explicit peer routes" and their interaction with other routes. - Document does not mention removal and modification at all - Comparison to other techniques is distributed in various section, maybe collect them in appendix (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. - 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 Thanks! Dhruv
- Re: [Teas] WG Last Call: draft-ietf-teas-pce-nati… zhu.chun1
- Re: [Teas] WG Last Call: draft-ietf-teas-pce-nati… xiong.quan
- [Teas] WG Last Call: draft-ietf-teas-pce-native-i… Lou Berger
- Re: [Teas] WG Last Call: draft-ietf-teas-pce-nati… Zhuangshunwan
- [Teas] 答复: WG Last Call: draft-ietf-teas-pce-nati… Fangsheng
- Re: [Teas] WG Last Call: draft-ietf-teas-pce-nati… Lizhenbin
- Re: [Teas] WG Last Call: draft-ietf-teas-pce-nati… Huaimo Chen
- Re: [Teas] WG Last Call: draft-ietf-teas-pce-nati… Pengshuping (Peng Shuping)
- Re: [Teas] WG Last Call: draft-ietf-teas-pce-nati… Dongjie (Jimmy)
- Re: [Teas] WG Last Call: draft-ietf-teas-pce-nati… Xiejingrong (Jingrong)
- Re: [Teas] WG Last Call: draft-ietf-teas-pce-nati… peng.shaofu
- Re: [Teas] WG Last Call: draft-ietf-teas-pce-nati… li_zhenqiang@hotmail.com
- [Teas] 答复: WG Last Call: draft-ietf-teas-pce-nati… Aijun Wang
- Re: [Teas] WG Last Call: draft-ietf-teas-pce-nati… Mike Koldychev (mkoldych)
- Re: [Teas] WG Last Call: draft-ietf-teas-pce-nati… Dhruv Dhody
- Re: [Teas] WG Last Call: draft-ietf-teas-pce-nati… Aijun Wang
- Re: [Teas] WG Last Call: draft-ietf-teas-pce-nati… Khasanov Boris
- Re: [Teas] WG Last Call: draft-ietf-teas-pce-nati… Lou Berger
- [Teas] 答复: WG Last Call: draft-ietf-teas-pce-nati… Aijun Wang