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

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 04 June 2021 12:57 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2833A0D09; Fri, 4 Jun 2021 05:57:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, 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 TQ9IChAWaT_B; Fri, 4 Jun 2021 05:56:56 -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 D6BA83A0D06; Fri, 4 Jun 2021 05:56:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4FxN7p0DSsz6GBtS; Fri, 4 Jun 2021 05:56:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1622811414; bh=rAUvNw5m/BNX9HQQ70PN2qAy8vuBpBog2x/tk+KLO20=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ZpzKwSv4OTx0qtZpKnJcrgjYIZ/1TR/EhMFUp2UTb2YWjSyW8HNgG/L0/EOylPF9w 0bLj0JUdHU2ocoYDmTUIl88d6EaqJGgU53ZrT8CTfjHu/rVHS4ctG5JlWliISY8R6O BePGuTnHZnyxDSxGRDDPuedxJwZTijWNIB/p+lWw=
X-Quarantine-ID: <VP_Lcm9RHsnZ>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4FxN7m4gbPz6GBqD; Fri, 4 Jun 2021 05:56:52 -0700 (PDT)
To: "Yangfan (IP Standard)" <shirley.yangfan@huawei.com>, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, 'Rishabh Parekh' <rishabhp@gmail.com>
Cc: "'spring@ietf.org'" <spring@ietf.org>, DetNet WG <detnet@ietf.org>
References: <101996923664441492159b346eee7d98@huawei.com> <MN2PR05MB598134731E9630AA07A9242CD42B9@MN2PR05MB5981.namprd05.prod.outlook.com> <e3e42fa3f59f4721acfd9e52f384fce8@huawei.com> <BL0PR05MB565206F9DC19DAE6CAD953CED4249@BL0PR05MB5652.namprd05.prod.outlook.com> <c12d4404dca3495c8417010138232694@huawei.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <0db6200a-4096-326d-1eb6-ba830d3fb20b@joelhalpern.com>
Date: Fri, 4 Jun 2021 08:56:44 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <c12d4404dca3495c8417010138232694@huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/6XRLJhqxoY30gcwcb2lzjsaVRBs>
Subject: Re: [Detnet] =?utf-8?b?W3NwcmluZ10g562U5aSNOiBSRTogQ29tbWVudHMgb24g?= =?utf-8?q?draft-geng-spring-sr-redundancy-protection?=
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jun 2021 12:57:01 -0000

Fan, I am a bit confused by your statement below.
the Detnet architecture, and the sublayer split therein, is not specific 
to SR-MPLS.  It applies as much to SRv6.  It would be very unusual, and 
need strong justification, for the SPRING WG to decide to change the 
published Detnet architecture.

Yours,
Joel (speaking as a participant)

On 6/4/2021 5:44 AM, Yangfan (IP Standard) wrote:
> Hi Jeffrey,
> 
> You are right about how redundancy protection is used in SR-MPLS. In 
> DetNet definition, S-label is purely functional not routable as it is in 
> service sub-layer. In the draft, we separate the redundancy segment 
> specification in two subsections, SR-MPLS and SRv6. For SR-MPLS, 
> redundancy segment obeys RFC8964. We are aligned on this point.
> 
> Regarding SRv6, DetNet doesn’t have SRv6 data plane specification, so 
> redundancy protection has no guide to follow. In the latest version of 
> draft, redundancy protection is defined to extend the capabilities in SR 
> paradigm to support the redundancy protection in a DetNet environment. 
> It should be allowed to define redundancy segment as a routable segment 
> in SRv6.
> 
> I will set aside time to reply to your other emails today. Thanks a lot! J
> 
> Fan
> 
> *发件人:*Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
> *发送时间:*2021年5月27日1:42
> *收件人:*Yangfan (IP Standard) <shirley.yangfan@huawei.com>om>; 'Rishabh 
> Parekh' <rishabhp@gmail.com>
> *抄送:*Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>om>; 'Rishabh 
> Parekh (riparekh)' <riparekh@cisco.com>om>; 'Arvind Venkateswaran 
> (arvvenka)' <arvvenka@cisco.com>om>; 'spring@ietf.org' <spring@ietf.org>
> *主题:*RE: [spring] RE: Comments on 
> draft-geng-spring-sr-redundancy-protection
> 
> Hi Fan,
> 
> More discussions on whether the redundancy/merging segment is a 
> topological/routable segment.
> 
> In case of SR-MPLS, draft-geng says:
> 
>     In SR over MPLS, Redundancy Segment acts as DetNet S-Label to
> 
>     explicitly identify the replication function on redundancy node.
> 
>     Redundancy segment is allocated from redundancy node, and is
> 
>     provisioned to the ingress node of SR domain by the controller plane
> 
>     via PCEP, BGP, or NetConf protocols.
> 
> According to RFC 8964:
> 
>     S-Label       A DetNet "service" label that is used between DetNet
> 
>                   nodes that implement the DetNet service sub-layer
> 
>                   functions.  An S-Label is used to identify a DetNet
> 
>                   flow at the DetNet service sub-layer at a receiving
> 
>                   DetNet node.
> 
> The S-label identifies the flow only. PRF/PEF/POF are not indicated by 
> the S-label, though the <S-label, SN> provides information needed for 
> PEF/POF.
> 
> Additionally, an S-Label certainly is not routable. If you consider the 
> redundancy node A and merging node D a pair of DetNet source/destination 
> node, adding PEF/POF semantics to an S-label may be reasonable (A 
> imposes the S-label and D knows that the S-label has merging semantics). 
> However, for the label that the ingress node imposes, which has both the 
> “route to A” and “Replicate by A” semantics, calling it an S-Label just 
> does not conform to RFC 8964.
> 
> In SRv6 case, while you could say that the redundancy segment is a 
> routable one, but that is true for an replication segment as well. An 
> SRv6 SID is a <locator, function, argument> tuple. A replication SID is 
> really just the “function” part, and the locator is used to get to the 
> node – whether it is a root, leaf or intermediate replication node.
> 
> Jeffrey
> 
> *From:*Yangfan (IP Standard) <shirley.yangfan@huawei.com 
> <mailto:shirley.yangfan@huawei.com>>
> *Sent:* Thursday, May 20, 2021 8:59 AM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net 
> <mailto:zzhang@juniper.net>>; 'Rishabh Parekh' <rishabhp@gmail.com 
> <mailto:rishabhp@gmail.com>>
> *Cc:* Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com 
> <mailto:gengxuesong@huawei.com>>; 'Rishabh Parekh (riparekh)' 
> <riparekh@cisco.com <mailto:riparekh@cisco.com>>; 'Arvind Venkateswaran 
> (arvvenka)' <arvvenka@cisco.com <mailto:arvvenka@cisco.com>>; 
> 'spring@ietf.org' <spring@ietf.org <mailto:spring@ietf.org>>
> *Subject:* 答复: [spring] RE: Comments on 
> draft-geng-spring-sr-redundancy-protection
> 
> *[External Email. Be cautious of content]*
> 
> Hi Jeff,
> 
> Thank you for your explanations about the SID list encapsulation and SID 
> process on each node. It did help a lot to understand how Replication 
> SID can be used in redundancy protection.
> 
> I move one of your comments from the other email here to focus on the 
> packet forwarding discussion in this thread.
> 
> As for the 3 deferred “homework”, feel free to come back when you are 
> available.
> 
> Much appreciated with these deep discussions. Some feedbacks please see 
> inline.
> 
> Regards,
> 
> Fan
> 
> *发件人:*Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net 
> <mailto:zzhang@juniper.net>]
> *发送时间:*2021年5月20日1:43
> *收件人:*Yangfan (IP Standard) <shirley.yangfan@huawei.com 
> <mailto:shirley.yangfan@huawei.com>>; 'Rishabh Parekh' 
> <rishabhp@gmail.com <mailto:rishabhp@gmail.com>>
> *抄送:*Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com 
> <mailto:gengxuesong@huawei.com>>; 'Rishabh Parekh (riparekh)' 
> <riparekh@cisco.com <mailto:riparekh@cisco.com>>; 'Arvind Venkateswaran 
> (arvvenka)' <arvvenka@cisco.com <mailto:arvvenka@cisco.com>>; 
> 'spring@ietf.org' <spring@ietf.org <mailto:spring@ietf.org>>
> *主题:*RE: [spring] RE: Comments on 
> draft-geng-spring-sr-redundancy-protection
> 
> Hi Fan,
> 
> Sorry for the late response. Please see zzh> below.
> 
> *From:*Yangfan (IP Standard) <shirley.yangfan@huawei.com 
> <mailto:shirley.yangfan@huawei.com>>
> *Sent:* Monday, May 17, 2021 9:20 AM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net 
> <mailto:zzhang@juniper.net>>; 'Rishabh Parekh' <rishabhp@gmail.com 
> <mailto:rishabhp@gmail.com>>
> *Cc:* Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com 
> <mailto:gengxuesong@huawei.com>>; 'Rishabh Parekh (riparekh)' 
> <riparekh@cisco.com <mailto:riparekh@cisco.com>>; 'Arvind Venkateswaran 
> (arvvenka)' <arvvenka@cisco.com <mailto:arvvenka@cisco.com>>; 
> 'spring@ietf.org' <spring@ietf.org <mailto:spring@ietf.org>>
> *Subject:* RE: [spring] RE: Comments on 
> draft-geng-spring-sr-redundancy-protection
> 
> *[External Email. Be cautious of content]*
> 
> Hi Jeffrey,
> 
> To summarize the discussions a bit, I have two questions and hope to 
> hear your comments and clarifications.
> 
> Q1: Are there any questionsfor clarifications or open issueswith the 
> current solution of redundancy-SID+Merging-SID+redundancy policy? If so, 
> we would like to clarify them first.
> 
> Zzh> No.
> 
> Fan1>> It is very good and important if the current redundancy 
> protection mechanism can be understood clearly in WG.
> 
> Q2:
> 
> Figure 1 in draft-geng-spring-sr-redundnacy-protection is the typical 
> topology for Redundancy Protection in SR domain, as shown below.
> 
> ingress------A (R)-------B-------D(M)-------egress
> 
>          +------C------------+
> 
>                      +----E-------+
> 
> Could you please explain how exactly Tree-SID solution is used in data 
> plane for redundancy protection? For example, how the SR SID List is 
> assigned, how the packet is encapsulated and forwarded from R1 to R2 in 
> data plane, how Tree-SID and Replication SID are configured on network 
> nodes, etc.
> 
> Zzh> I sort of replied in my late response to the other email, but let 
> me reply here as well because that thread was indeed getting very deep.
> 
> Zzh> I changed the letters so that we can distinguish between node 
> representation and function representation. A is the redundancy node and 
> D is merging node. I also added another node E.
> 
> Zzh6> Unlike unicast where you use a segment list to encode the path 
> that a packet flows through, with multicast it is impractical to encode 
> a (sub-)tree as a segment list. Therefore, for SR-P2MP, an replication 
> tree is not represented by a segment list. Rather, each 
> root/replication/leaf node on a tree installs a replication segment to 
> represent how replication is done on that node for that tree, and only 
> one SID is needed in the packet for it to flow from the root to all the 
> leaves through the intermediate replication points. This is exactly like 
> today’s P2MP tunnel in the forwarding plane. We can put aside the 
> argument “oh this requires per-flow state” here, as it is not relevant 
> to our topic here.
> 
> Fan1>> To differentiate the node representation and function 
> representation actually reveals a significant difference between 
> Replication SID and Redundancy SID.  In terms of SRv6, Replication 
> Segment is a local and non-routed segment, and Redundancy Segment is a 
> routed segment. And the merging segment in redundancy protection is also 
> a routed (topological) SID with merging function.
> 
> As you mentioned, it is impractical to use a segment list to encode a 
> tree for multicast traffic. So Replication SID only represents the 
> replication function, moreover is designed to separate with the routed 
> Node SID, however the benefit is Replication SID can be identical on one 
> tree.
> 
> Meanwhile, Redundancy Segment is usually used for unicast traffic, it is 
> straightforward to design it as a routed and functional segment. It is 
> not necessary to separate the route and function apart into different 
> SIDs, at least it saves one 128bit SID space.
> 
> Zzh> Let’s say that we’ll only make two copies for D to receive. A and D 
> have replication segment R installed. R on A simply says “make two 
> copies, one through B and one through C”. B/C do not need any state 
> because A is simply going to tunnel through B/C respectively. R on D 
> simply says “I am a leaf so I just pop R”.
> 
> Zzh> The ingress will send packets with SL <A, R, M>. SID A gets the 
> packet to A, who sees R and do the replication (R is not popped by A). D 
> sees R in the SL and pops R (this is the replication segment behavior on 
> a leaf). It then sees M and do the merging. Alternatively, A could pop R 
> so D will see M directly and do the merging.
> 
> Zzh> Now let’s say we want to make three copies. The ingress will still 
> send the same SL. R on A now says “tunnel one copy to D through B and 
> send one copy to C” and C now also has R installed, saying “send one 
> copy to D directly and another copy to D via E”. Now three copies will 
> arrive on D (with A/C each replicating once). D sees R SID and pops the 
> R SID (as the behavior of replication segment on leaf). It then sees M 
> and do the merging.
> 
> Zzh> The replication is pure SR-P2MP behavior (assuming A does not need 
> to add FI/SN). M is pure non-topological merging behavior (relying on 
> the FI/SN added by the ingress node).
> 
> Fan1>> Thanks for your detailed explanations in this and other email, 
> now I think I understand how data plane works.  There are still details 
> needs further discussion,  e.g. in terms of SRv6, if B/C is downstream 
> nodes, in this sentence “D sees R SID and pops the R SID” pop means 
> remove the IPv6 header, in this case M SID will not be processed. But 
> that’s all right, there are surely a lot details if you want to design 
> one unified Segment can work for P2MP multicast and redundancy 
> protection, also unified in SR-MPLS and SRv6. We can surely continue the 
> discussions.
> 
> Zzh> Thanks.
> 
> Zzh> Jeffrey
> 
> I don’t think I understand the entire forwarding flow correctly. In fact 
> we are very interested in Tree-SID solution as it has been adopted as a 
> WG work. It would be very helpful if you or anyone can provide a 
> detailed illustration or comparison, for instance like the way of the 
> Appendix in replication SID/Tree SID drafts.
> 
> Looking forward to your reply!
> 
> Best,
> 
> Fan
> 
> Juniper Business Use Only
> 
> Juniper Business Use Only
> 
> 
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>