Re: [spring] 答复: Comments on draft-geng-spring-sr-redundancy-protection

Rishabh Parekh <rishabhp@gmail.com> Wed, 14 April 2021 19:10 UTC

Return-Path: <rishabhp@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA923A1C1B for <spring@ietfa.amsl.com>; Wed, 14 Apr 2021 12:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.986
X-Spam-Level:
X-Spam-Status: No, score=-1.986 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 Jb96O6_DC73Z for <spring@ietfa.amsl.com>; Wed, 14 Apr 2021 12:10:33 -0700 (PDT)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 C927B3A1C15 for <spring@ietf.org>; Wed, 14 Apr 2021 12:10:32 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id o20-20020a05600c4fd4b0290114265518afso11086724wmq.4 for <spring@ietf.org>; Wed, 14 Apr 2021 12:10:32 -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=TXwTROf2pHQk7Nx/FwSOupfAa8hEC8Gk0mrfcAfx6bE=; b=M0K/Vv4gwuHWBxCocmY5ZWf+JBsHq8o7RrlTKSUksrzvcT9q6hRnrS2mM8pB0nf6pC dVhiVpvWVCR5ZI/yOTx3r1c1V32nO4iHco7KYFPsBQaxzNdOuWILLRDI0MHJkcb2pqta +L2ekLs7YWK22de5L+fbVFJZJLTpOtFBeXt49P2VQLgreGCMw0rc5dMQXK/eNtQqGf58 kR5fH7L+XfgJc59Lec4bRAtE98hmVLQhYqvzA5tXk69whgoUOJpjPqKRudwQ6pSX2/FD QG1rsWwTPumA7Rzmt7nlW7FmyxFuX16lmtkriRcy+50/9fEPY2ab8KT6Xsri9ySm6OAM x21w==
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=TXwTROf2pHQk7Nx/FwSOupfAa8hEC8Gk0mrfcAfx6bE=; b=mn61n8kGH4CkfG+tdev/bIY2btdS4DcHMWBwQGcx9F1XYEwFrEkvT5zlE27jsudezk gfSajhW4sRrLxfc10eg4StTXqyifcZt6BizcJ+cZTcogVAz0iozr4XYw61toc2PvGls4 GkAH0lk132YQQlivQ9U7D1vQPynh2Dj4Z+hi9W+OlhcVvPxqjb4ZS4EsGjf2LdIC1Bln SlpG/LYWLVRBon3El3F6/Y3bUZqI1QAo84bjU4xjw6iWtvry45x7hdPbjV/R89pzT/hz aaBUkkH/GsrzPpjjYME3GkaDsm+fIqLUZdo+shp1hYpwbe9EX29xxXHJLACD3+Ybij6F t+YQ==
X-Gm-Message-State: AOAM532LiOt7Y/JwehPuAvAFPa6othQUdXHmb8EMxPt3KWSK5m7p0XJP ClMCQENDM1HF7KMcIXMUN9Lypuli841bXzCiA/U=
X-Google-Smtp-Source: ABdhPJwHHciK7zx9QjG4DTg6xWMG53gNBjGUfUQUmDcNJMXuCVKnL/nIxJ/arTAUKwY1ie2oMxGyM+7R0E+GUToFglg=
X-Received: by 2002:a05:600c:4f15:: with SMTP id l21mr4557965wmq.134.1618427428119; Wed, 14 Apr 2021 12:10:28 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR05MB59812099F115C3FF43CA9077D4629@MN2PR05MB5981.namprd05.prod.outlook.com> <59384be985ae4d3bb9563bed2642bff1@huawei.com> <BYAPR11MB300030B313D45266695FA702DE7E9@BYAPR11MB3000.namprd11.prod.outlook.com> <MN2PR05MB5981AA3B0A5E0D6DDB60F46FD47E9@MN2PR05MB5981.namprd05.prod.outlook.com> <1e2ad2d64da24714bc50f64b3d39361f@huawei.com>
In-Reply-To: <1e2ad2d64da24714bc50f64b3d39361f@huawei.com>
From: Rishabh Parekh <rishabhp@gmail.com>
Date: Wed, 14 Apr 2021 12:10:16 -0700
Message-ID: <CABjMoXbTqmqPg6n7No1u7g3KZPFDDb8RX6CQgxZc1oWQnykTng@mail.gmail.com>
To: "Yangfan (IP Standard)" <shirley.yangfan@huawei.com>
Cc: "Jeffrey (Zhaohui) Zhang" <zzhang=40juniper.net@dmarc.ietf.org>, "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>, "Rishabh Parekh (riparekh)" <riparekh@cisco.com>, "Arvind Venkateswaran (arvvenka)" <arvvenka@cisco.com>, "spring@ietf.org" <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f2a8cc05bff37feb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/vWkXLHD59UIe8v4qnydt-BjCGM8>
Subject: Re: [spring] =?utf-8?b?562U5aSNOiBDb21tZW50cyBvbiBkcmFmdC1nZW5nLXNw?= =?utf-8?q?ring-sr-redundancy-protection?=
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Apr 2021 19:10:38 -0000

Fan,

Zzh> RFC 8986 does specify additional flavors of End and End.X function
with USP, PSP and USD behaviors which are modifications to base End and
End.X function; exactly what we are proposing here – enhancing Replication
Segment to add (FI,SN) when required.

Fan>> can you explain more? I don’t see correlation between flavors and
adding (FI,SN).

Fan>> after seeing all these “if, then” shown above, I even feel more
strongly to support separating two segments. J In RFC8986, there is no
single Endpoint behavior having such “if, then” structure to specify
different functions.



RP> What Jeffrey means is RFC 8986 already has a precedent of defining
functionality, End and End.X, with slight modifications to basic behavior –
these are the PSP, USP and USD variants. An implementation that supports
these flavors has to have “if-then-else” logic to deal with active SIDs for
End and End.X segments with different flavors.

RP> We are proposing the same approach here; modify base Replication
segment behavior to add (FI,SN) if required. Also note that the definition
of Replication segment already has “if-then-else” built in to deal with
decapsulation on a Leaf node, or replication to downstream nodes, or to do
both on a Bud node.


-Rishabh


On Thu, Apr 8, 2021 at 6:25 AM Yangfan (IP Standard) <
shirley.yangfan@huawei.com> wrote:

> Hi Jeffrey,
>
> Apology for being so late to reply. Please see inline starts with Fan>>.
>
>
>
> Cheers,
>
> Fan
>
>
>
> *发件人:* spring [mailto:spring-bounces@ietf.org] *代表 *Jeffrey (Zhaohui)
> Zhang
> *发送时间:* 2021年3月30日 5:06
> *收件人:* Yangfan (IP Standard) <shirley.yangfan@huawei.com>om>; Gengxuesong
> (Geng Xuesong) <gengxuesong@huawei.com>om>; 'Rishabh Parekh (riparekh)' <
> riparekh@cisco.com>gt;; 'Arvind Venkateswaran (arvvenka)' <arvvenka@cisco.com>om>;
> spring@ietf.org
> *主题:* Re: [spring] Comments on draft-geng-spring-sr-redundancy-protection
>
>
>
> Hi Fan,
>
>
>
> Please see zzh> below.
>
>
>
> *From:* Yangfan (IP Standard) <shirley.yangfan@huawei.com>
> *Sent:* Friday, March 26, 2021 11:58 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org>rg>;
> Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>om>; spring@ietf.org;
> Rishabh Parekh (riparekh) <riparekh@cisco.com>om>; Arvind Venkateswaran
> (arvvenka) <arvvenka@cisco.com>
> *Subject:* 答复: Comments on draft-geng-spring-sr-redundancy-protection
>
>
>
> Hi Jeffrey,
>
>
>
> Thank you for the comments, please see the reply inline starts with [FY#].
>
>
>
> Cheers,
>
> Fan
>
>
>
>
>
> -----邮件原件-----
> 发件人: spring [mailto:spring-bounces@ietf.org <spring-bounces@ietf.org>] 代表
> Jeffrey (Zhaohui) Zhang
> 发送时间: 2021年3月26日 3:19
> 收件人: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>om>; spring@ietf.org;
> Rishabh Parekh (riparekh) <riparekh@cisco.com>om>; Arvind Venkateswaran
> (arvvenka) <arvvenka@cisco.com>
> 主题: [spring] Comments on draft-geng-spring-sr-redundancy-protection
>
>
>
> Hi Xuesong, Mach, Fan,
>
>
>
> Some comments/questions on the proposal.
>
>
>
> 1. We don't need an additional "redundancy segment" for the replication
> semantics. Existing "replication segment"
> (draft-ietf-spring-sr-replication-segment) can be used as is, especially
> for the scenario where the original header already carries (FI, SN)
> information.
>
> ------[FY1]: three considerations here:
>
> a). For the scenario you mentioned, that is correct, redundancy segment
> and replication segment share a common behavior of "packet duplication".
> The significant difference between two segments is the behavior of adding
> FI and SN. Unfortunately, there is no application in SRv6 required to carry
> (FI,SN) information in IPv6 header, which results in a more common scenario
> is where the original packet doesn't carry (FI, SN). So the current design
> of redundancy segment is based on this scenario.
>
>
>
> Zzh> Since the presentation talked about scenario where the (FI, SN)
> information is already carried, it is fair to discuss that in my initial
> comments; I understand that you want to focus on the other scenario, and
> that’s fine – see later comments below.
>
>
>
> Fan>> I read the draft of replication segment, and have two questions if
> replication segment is used in redundancy protection.
>
> 1) I believe merging node should be as the downstream node, since the
> nodes in precedence of merging node should not be redundancy protection
> aware. In this case, there will be at least two identical downstream nodes.
> In replication segment, there is no definition of such a situation.
>
> 2) The draft states replication SID MUST only appear as the ultimate SID
> in a SID list. What if the merging node is not the last node of the SRv6
> E2E path?
>
>
>
> b). Even though IPv6 flow label could be encapsulated in header, it is
> used for ECMP or fragmentation, redundancy protection cannot simply reuse
> it since flow ID allocation has dependency on the merging node capability.
>
>
>
> Zzh> IPv6 flow label is irrelevant here – it’s not discussed in either
> your draft/presentation or in my comments – so we can ignore this.
>
> Fan>> I mentioned IPv6 flow label coz we had this discussion in DetNet WG.
> I agree we can come back to this thread when it is needed.
>
>
> https://mailarchive.ietf.org/arch/browse/detnet/?q=flow%20identification%20in%20ipv6
>
>
>
> c). In protocol design, it is important to maximally reuse the existing
> implementation. However, instantiation of a segment is a different story.
> In RFC8986, there are 14 End behaviors and 4 headend behaviors defined. We
> understand the principle here is to keep the semantics of a segment and
> further functions definition neat to make the segment routing forwarding
> clear and efficient. To enhance the replication segment to support
> redundancy segment seems quite an opposite methodology.
>
>
>
> Zzh> RFC 8986 does specify additional flavors of End and End.X function
> with USP, PSP and USD behaviors which are modifications to base End and
> End.X function; exactly what we are proposing here – enhancing Replication
> Segment to add (FI,SN) when required.
>
> Fan>> can you explain more? I don’t see correlation between flavors and
> adding (FI,SN).
>
>
>
> 2. Even for the scenario where the (FI, SN) information needs to be added
> by the redundancy node, the existing "replication segment" can be enhanced
> to add the (FI, SN) information.
>
> -----[FY2]: Replication segment provides P2MP replication with target of
> supporting multicast service, and redundancy segment aims to provide
> redundant flow protection to URLLC services. Adding (FI, SN) doesn’t
> bring value to multicast services, and having the stitching capability of
> replication on redundancy node seems a waste and unpractical to URLLC
> service. Twisting them together in one segment results in a complicated
> function, where maybe only one type of service is required on the node.
>
>
>
> Zzh> Adding (FI, SN) information is only to replication segments that are
> used for replication for unicast redundancy purpose. It does not mean all
> replication segments will be added with (FI, SN) semantics.
>
>
>
> Fan>> How would you write the Boolean switch to differentiate the purpose
> of multicast replication and redundancy protection in one segment? And
> currently we don’t exclude the redundancy protection for multicast traffic.
>
>
>
> Zzh> I don’t follow your argument about “seems a waste and unpractical to
> URLLC service”.
>
>
>
> Zzh> I don’t follow your argument about “Twisting them together in one
> segment results in a complicated function where maybe only one type of
> service is required on the node” either. If you only need regular multicast
> service, the replication segment does not need the semantics to add (FI,
> SN) information. If you need redundancy protection then the replication
> segment does have the semantics to add (FI, SN) information). If you need
> both, then some will have that semantics and some will not; and if you have
> a scenario where you don’t need to add (FI, SN) information for redundancy
> protection then the existing replication segment w/o the additional
> semantics to add (FI, SN) information can be used for both. All can be
> achieved with a simple Boolean switch added to the replication segment.
>
> Fan>> after seeing all these “if, then” shown above, I even feel more
> strongly to support separating two segments. J In RFC8986, there is no
> single Endpoint behavior having such “if, then” structure to specify
> different functions.
>
>
>
> Zzh> Note that Replication Segment is not tied to multicast either (the
> draft only mentioned multicast once as one use case):
>
>
>
>    We define a new type of segment for Segment Routing [RFC8402 <https://tools.ietf.org/html/rfc8402>], called
>
>    Replication segment, which allows a node (henceforth called as
>
>    Replication Node) to replicate packets to a set of other nodes
>
>    (called Downstream Nodes) in a Segment Routing Domain. Replication
>
>    segments provide building blocks for Point-to-Multipoint Service
>
>    delivery …
>
>
>
> Zzh> It is about replicating packets to a set of other nodes – quite
> applicable here as a building block.
>
> Fan>> I do think replication segment has a very elegant design, however
> identical downstream nodes, design of P2MP SR policy (indirectly involves
> Tree-ID) may seem burden too much on redundancy segment. But it is still
> very welcome to have further discussion on replication segment and
> redundancy segment.
>
>
>
> 3. I wonder why (FI, SN) information is added as a TLV in the SRH. Would
> it be better to use DOH?
>
> -----[FY3]: If the (FI,SN) is encapsulated in type of TLV, both SRH and
> DOH are feasible. Actually (FI,SN) information is only meaningful to
> merging node, putting them in the arg part of replication segment doesn't
> help.
>
>
>
> Zzh> While I do think it is better to put the actual (FI, SN) information
> in the DOH, I did not talk about adding (FI, SN) information to the arg
> part of an SRv6 SID. I was saying that the argument of an SRv6 replication
> SID can serve as that Boolean switch to indicate if (FI, SN) information
> needs to be added.
>
> Fan>> so far, this approach works for me.
>
>
>
> For #1, and #2, reusing/enhancing existing replication segment has the
> following benefits:
>
>
>
> a. Reduce protocol/implementation work
>
> b. Reduce the amount of state in the network (the same P2MP tunnel can be
> used for both multicast traffic and unicast redundancy)
>
>
>
> b) can be achieved even with #2 (redundancy node needs to add (FI, SN)
> information): for SRv6, the semantics of adding (FI, SN) can be indicated
> by the arg part of the replication SID and for SR-MPLS it can be indicated
> by an additional label in front of the replication sid label. If using an
> addition label is a concern, then indeed a single label can be used to
> indicate both "add FI/SN information" and "replicate", but still the
> replication semantics can still be set up using the replication segment
> infrastructure.
>
>
>
> For SR-MPLS, where would you put the (FI, SN) information? Seems that GDFH
> (draft-zzhang-intarea-generic-delivery-functions) is a good option and that
> can be used for SRv6 as well (anything in DOH that is actually independent
> of IP could be extracted out to GDFH).
>
> -----[FY4]: For SR-MPLS, currently the authors plan to keep consistent
> with specification in RFC8964. The original intention of this draft is to
> provide a PREOF solution in SR data plane to DetNet. What's why the draft
> is discussed first in DetNet then comes to SPRING. And FYI, DetNet MPLS
> data plane uses a separate service label (S-Label) and PW MPLS Control Word
> [RFC4385] to carry FI and SN.
>
>
>
> Zzh> I forgot that DETnet mpls data plane already reuses PW CW for SN
> information. That’s fine and no need to introduce GDFH for MPLS.
>
> Zzh> Thanks.
>
> Fan>> thanks for bring up this topic to a deeper discussion. Redundancy
> protection should be taken into consideration for both SP and vendor if
> URLLC services should be guaranteed.
>
>
>
> Zzh> Jeffrey
>
>
>
> Thanks.
>
>
>
> Jeffrey
>
>
>
> Juniper Business Use Only
>
> _______________________________________________
>
> spring mailing list
>
> spring@ietf.org
>
> https://www.ietf.org/mailman/listinfo/spring
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Rk0PGf0pg0nFb0yo3yrw4HCuRzBBn_xDVWjwUQ9HKkn1db_vI48SfuShKITTo6uG$>
>
>
>
> Juniper Business Use Only
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>