From nobody Mon Jul 26 23:48:17 2021 Return-Path: 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 28FAE3A17F3; Mon, 26 Jul 2021 23:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_FONT_FACE_BAD=0.001, HTML_MESSAGE=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 on1pCTKr2hVx; Mon, 26 Jul 2021 23:48:06 -0700 (PDT) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 B29333A17F6; Mon, 26 Jul 2021 23:48:05 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id a4-20020a17090aa504b0290176a0d2b67aso2761030pjq.2; Mon, 26 Jul 2021 23:48:05 -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=MFYORb5MPKlL7J+U/lGYWUpXRNIUqkzMy27joBtSuAs=; b=n13wds6Lu4GJSxg5qWWi40A5I62iCWIpvNjKKb2Plv0mtVR/x+7gZVLZtMtFwuD+xl WItVkepqW1eickvgEv++St55yTpK7fiBmSGG2/c1hP+yhGlXDuGs/851Ao8Qs3UbL3mc ya0nXwSVT36nINaYTDxkK5P1QPOEUYjxSBlqCu8t+lXOXtoM0U1ymt/GR4Sp2hFILAVZ lxIdM3fMpm00xZ3a2OiPNpX0IR7FOAO/kpNb49UOYy71zw++m1tbvMLKrCctY/cQD0Ob KuaDT13Y9vgorHMcm5UQG3k4oc6J4aOHbvwk9HnSa4+/r6gQIYDg7n80UVbVWWcGRbDN Px8A== 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=MFYORb5MPKlL7J+U/lGYWUpXRNIUqkzMy27joBtSuAs=; b=I6aRRBt3l+79xQI1atHbhzTPwZRqPoNnQ98L5A5vAl1oW6bf/ZKASGy2COAC0wpS0h Y1eYarMfxoxjbqs+txbxxrdAhkvZINTD6P7Mm9m4C6A6FBkd0FcQzkB2foSF/hZ3Nikg Tc9KZGtkqRF782AdQ9HmnrECR2/Vi9ueIENAGeH2L4AJMySQt3p2Q/t+bSbrqwT97z2Q 2INJ6mG/5VaBarfUcFHwrALCPRWxNn7ONKOOZBEOBDsHHlJkzZlglJh/SriaqL423/cd 1zwShEZ3Zdp/Du7yyY4IPeC4b0A14rxmSbQjWdKQAOfUcrlQ0yoeY/eSOEN/t9UO5Y80 lgrA== X-Gm-Message-State: AOAM5332Beih5ShkxQSM4ahpN1N+ePPSupvlvvpSjt7/IfBe5sZCIH65 1g8zY9hpfVZ4dYWOpysMzCO+47aFhPQJWk6KauI= X-Google-Smtp-Source: ABdhPJww/McBSx/V5+l0T2Im4eTUdFiLtSADs/uUI5aAOFDp3HZ/K7eGnO3JlmLGvaQs2EjBHHiZ52IFPMMtB3x3fps= X-Received: by 2002:a62:6103:0:b029:396:f515:94bf with SMTP id v3-20020a6261030000b0290396f51594bfmr9934912pfb.4.1627368484001; Mon, 26 Jul 2021 23:48:04 -0700 (PDT) MIME-Version: 1.0 References: <047f01c93fde45aeaa2dfc6147bbf5c4@huawei.com> <202107271216066084183@zte.com.cn> In-Reply-To: <202107271216066084183@zte.com.cn> From: Gyan Mishra Date: Tue, 27 Jul 2021 02:47:52 -0400 Message-ID: To: gregory.mirsky@ztetx.com Cc: balazs.a.varga@ericsson.com, detnet@ietf.org, draft-geng-spring-sr-redundancy-protection@ietf.org, shirley.yangfan@huawei.com, spring@ietf.org Content-Type: multipart/related; boundary="00000000000068f7cf05c815400a" Archived-At: Subject: Re: [Detnet] =?utf-8?b?562U5aSNOiBJRVRGLTExMSBTUFJJTkcgcHJlc2VudGF0?= =?utf-8?q?ion_on_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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 06:48:11 -0000 --00000000000068f7cf05c815400a Content-Type: multipart/alternative; boundary="00000000000068f7ce05c8154009" --00000000000068f7ce05c8154009 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Greg Redundancy Protection positioned for both SRv6 and SR-MPLS and can address all use P2P cases extending SR functionality. That is the new goal of the draft. At this time DETNET is out of scope and we will update the draft to reflect= . >From a DETNET perspective my thoughts are that excluding P2MP DETNET requirements as far as the forwarding and service sub layer it is possible that redundancy protection could meet the DETNET requirements if you think of the Replication and Merge SIDs as service SIDs acting at the DETNET service sub layer with SRH TLV S label set it is possible. I think the lines are more blurred with SRv6 trying to fit into the DETNET service and forwarding sub layers but I think it=E2=80=99s still possible when you thin= k of the two new redundancy protection SIDs are treated as service SIDs sitting at the DETNET service sub layer. Kind Regards Gyan On Tue, Jul 27, 2021 at 12:16 AM wrote: > Hi Fan, > > thank you for the detailed explanation of the author's view of the scope > of the draft. As the proposed mechanism is being positioned as a generic > for SRv6, it seems logical that it addresses all the use cases. That, in = my > opinion, would include p2p and p2mp SR policies and DetNet in SR with IPv= 6 > data plane. Would you agree? > > > Regards, > > Greg Mirsky > > > Sr. Standardization Expert > =E9=A2=84=E7=A0=94=E6=A0=87=E5=87=86=E9=83=A8/=E6=9C=89=E7=BA=BF=E7=A0=94= =E7=A9=B6=E9=99=A2/=E6=9C=89=E7=BA=BF=E4=BA=A7=E5=93=81=E7=BB=8F=E8=90=A5= =E9=83=A8 Standard Preresearch Dept./Wireline Product R&D > Institute/Wireline Product Operation Division > > > > E: gregory.mirsky@ztetx.com > www.zte.com.cn > Original Mail > *Sender: *Yangfan(IPStandard) > *To: *Bal=C3=A1zs Varga A;draft-geng-spring-sr-redundancy-protection@ietf= .org; > *CC: *spring;detnet@ietf.org; > *Date: *2021/07/26 14:09 > *Subject: **[Detnet] =E7=AD=94=E5=A4=8D: IETF-111 SPRING presentation on > sr-redundancy-protection* > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > > Hi Balazs, > > > > Thank you for your comments. > > As what Gyan mentioned during the presentation, this draft redefines > redundancy protection as a general protection mechanism designed for SR > network. Firstly, it is a general mechanism can be used in many uses case= s, > not only DetNet use case. Secondly, it applies to SR network, not a gener= al > IP or MPLS data plane solution which Detnet requires. Since the scope is > changed, I don=E2=80=99t think redundancy protection is necessary to foll= ow DetNet > architecture. > > If redundancy protection is not a DetNet mechanism, I don=E2=80=99t think= it > should cover both P2P and P2MP services. > > We are happy to address the comments that relates to redundancy protectio= n > in next revision. > > > > Thanks. > > Fan > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Bal=C3=A1zs Varga A [mailto:balazs.a.varga= @ericsson.com] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2021=E5=B9=B47=E6=9C=8827=E6=97= =A5 4:49 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* draft-geng-spring-sr-redundancy-protection= @ietf.org > *=E6=8A=84=E9=80=81:* spring ; detnet@ietf.org > *=E4=B8=BB=E9=A2=98:* IETF-111 SPRING presentation on sr-redundancy-prote= ction > > > > Hi, > > > > As time not permitted comments during the SPRING meeting, major comments > regarding the > > redundancy protection presentation: > > > https://datatracker.ietf.org/meeting/111/materials/slides-111-spring-sr-f= or-redundancy-protection-00 > > > > 1, General: despite the reference to DetNet this draft is not compliant > with Figure 1 of RFC8655 (DetNet Architecture) > > 2, Slide-9: DetNet provides both p2p and p2mp services. This draft only > p2p, so many DetNet use cases cannot be supported > > 3, Slide-9: there were many DetNet related comments on the list. Only som= e > were addressed in the latest version of the draft. > > > > Thanks & Cheers > > Bala=E2=80=99zs > > > > > > > > > > > > > > *From:* Jeffrey (Zhaohui) Zhang > *Sent:* Monday, July 19, 2021 11:44 PM > *To:* Yangfan (IP Standard) ; Bal=C3=A1zs Var= ga A < > balazs.a.varga@ericsson.com>; > draft-geng-spring-sr-redundancy-protection@ietf.org > *Cc:* spring ; detnet@ietf.org > *Subject:* RE: SR and DetNet, draft on sr-redundancy-protection > > > > Hi Fan, > > > > Catching up on this late =E2=80=A6 > > > > You said: > > > > =C3=98 Triggered by the discussions in SPRING, I think we can define > redundancy segment and merging segment as a functional segment without > routing and topological semantics, and use different segment for the > routing purpose. Thus, redundancy segment and merging segment are segment= s > with pure service semantics and don=E2=80=99t violate the sub-layers defi= nition in > DetNet architecture. > > > > Are you alluding to using replication segment for the routing/forwarding > purpose? In my late response to an old email of yours that I just sent ( > https://mailarchive.ietf.org/arch/msg/spring/YyEb8kGgtXxITZaIGyxynp9wh9s/= ), > I also said =E2=80=9Cthe redundancy/merging functionality can be consider= ed as an > overlay service that makes use of replication underlay service=E2=80=9D = =E2=80=93 so maybe > we=E2=80=99re converging? > > > > Thanks. > Jeffrey > > > > *From:* spring *On Behalf Of *Yangfan (IP > Standard) > *Sent:* Saturday, June 12, 2021 2:07 AM > *To:* Bal=C3=A1zs Varga A ; > draft-geng-spring-sr-redundancy-protection@ietf.org > *Cc:* spring ; detnet@ietf.org > *Subject:* [spring] =E7=AD=94=E5=A4=8D: SR and DetNet, draft on sr-redund= ancy-protection > > > > *[External Email. Be cautious of content]* > > > > Hi Bala=E2=80=99zs, > > Thank you for your comments. Please see my reply inline starts with Fan1>= > > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Bal=C3=A1zs Varga A [mailto:balazs.a.varga= @ericsson.com > ] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2021=E5=B9=B46=E6=9C=8811=E6=97= =A5 21:12 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* draft-geng-spring-sr-redundancy-protection= @ietf.org > *=E6=8A=84=E9=80=81:* detnet@ietf.org; spring > *=E4=B8=BB=E9=A2=98:* SR and DetNet, draft on sr-redundancy-protection > > > > Hi Authors, > > > > thanks for the update of your draft, to clarify the proposed mechanism of > > redundancy protection. > > > > I have concerns regarding this draft as (1) the SRv6 approach does not > follow the > > DetNet architecture, and (2) repeats functionalities that are provided by > the DetNet > > service sub-layer but with serious limitations. > > > > (1) DetNet has defined two sub-layers: the service sub-layer and the > forwarding > > sub-layer. The service sub-layer is responsible for service protection an= d > the > > forwarding sub-layer provides forwarding paths and resource allocation on > top of > > them for the DetNet flows. DetNet specifications allow to use any > technology in > > the forwarding sub-layer, including Segment Routing. > > > > The SRv6 approach described in > "draft-geng-spring-sr-redundancy-protection" breaks > > the clear concept of the sub-layers by mixing them up. It contradicts to > several > > points at least to RFC8655 (DetNet Architecture), RFC8938 (Data Plane > Framework) > > and RFC8964 (DetNet MPLS Data Plane). > > > > Fan1>> Segment routing extends IPv6 by introducing SRH extension header > and SID programming. From the perspective of SID list in SRH, it provides > the explicit route to IPv6 data plane in forwarding sub-layer. From the > perspective of SID programming and Endpoint behaviors, it provides the > packets replication and elimination in service sub-layer. So Redundancy > segment could include the routing characteristic and service indication a= t > the same time. Similar happens to Merging segment. I think this is why yo= u > called it breaking the concepts of two sub-layers and mixing them up. > > Triggered by the discussions in SPRING, I think we can define redundancy > segment and merging segment as a functional segment without routing and > topological semantics, and use different segment for the routing purpose. > Thus, redundancy segment and merging segment are segments with pure servi= ce > semantics and don=E2=80=99t violate the sub-layers definition in DetNet > architecture. > > Besides, in RFC8655 4.1.2 DetNet data-plane overview, it says, > > This separation of DetNet sub-layers, while helpful, should not be > considered a formal requirement. For example, some technologies may viola= te > these strict sub-layers and still be able to deliver a DetNet service > > I think SRv6 could be acceptable based on this. > > > > In addition, I guess where to encapsulate meta data could be one concern. > According to DetNet, they should be identified and encapsulated at SR edg= e > node. We plan to include both possibilities in next update. To carry them > at SR edge node would be recommended as the first choice, and thus does n= ot > violate DetNet architecture. Right now I still want to keep the possibili= ty > for redundancy segment to add meta data for some corner case. > > > > So far, I didn=E2=80=99t realize there are other points contradict to Det= Net RFCs. > We are very happy to discuss them. > > > > (2) The motivation for "draft-geng-spring-sr-redundancy-protection" is no= t > clear especially > > as the SRv6 approach seems to be repeating DetNet service sub-layer > functionalities; however, > > with a limited set of functionalities without any clear benefits. > > Fan1>> as what I said in previous email to Joel, redundancy protection > comes from service protection specified in DetNet, but more focus on how = to > do it when Segment Routing is introduced to MPLS and IPv6. Currently, > DetNet defines IP and MPLS data planes for DetNet in RFC8939 and RFC8964. > There is segment routing consideration in RFC8964, but not in RFC8939. In > our draft, we try to focus on definition in SRv6, and for MPLS-SR just > obeys the specifications in RFC8964. It is clear that we are not repeatin= g > DetNet service sub-layer functionality, but to fill the gap between RFC89= 39 > and SRv6. If WG thinks the SR-MPLS sections are redundant, we can take > reference from RFC8964 for simplicity in next update. > > I don=E2=80=99t think there is no clear benefit what segment routing brin= gs to > IP(v6). By using the redundancy protection mechanism, DetNet services > running over SRv6 don=E2=80=99t rely on IP+UDP/TCP tuple to provide PREOF= . The > authors believe this draft is meaningful. > > Thank you for bring this topic into DetNet and SPRING. I take it as > whether SRv6 is worth to be specified separately besides the existing > DetNet data plane RFCs. It is a valid and important question for DetNet, = we > may need some guide from the WG. > > My 2 cents. > > > > Best regards, > > Fan > > > > > > Cheers > > Bala'zs > > > > Juniper Business Use Only > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --00000000000068f7ce05c8154009 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Greg=C2=A0

<= /div>
Redundancy Protection positioned for both =C2=A0SRv6= =C2=A0and SR-MPLS and can address all use P2P cases extending SR functiona= lity.=C2=A0 That is the new goal of the draft.

<= /div>
At this time DETNET is out of scope and we will upda= te the draft to reflect.

From a DETNET perspective my thoughts are that excluding P2MP DETNET requi= rements as far as the forwarding and service sub layer it is possible that = redundancy protection could meet the DETNET requirements if you think of th= e Replication and Merge SIDs as service SIDs acting at the DETNET service s= ub layer with SRH TLV =C2=A0S label set it is possible.=C2=A0 I think the l= ines are more blurred with SRv6 trying to fit into the DETNET service and f= orwarding sub layers but I think it=E2=80=99s still possible when you think= of the two new redundancy protection SIDs are treated as service SIDs sitt= ing at the DETNET service sub layer. =C2=A0

Kind Regards=C2=A0

Gyan =C2=A0


On Tue, Jul 27, 2021 at 12:16 AM <gregory.mirsky@ztetx.com> wr= ote:

Hi Fan,

thank yo= u for the detailed explanation of the author's view of the scope of the= draft. As the proposed mechanism is being positioned as a generic for SRv6= , it seems logical that it addresses all the use cases. That, in my opinion= , would include p2p and p2mp SR policies and DetNet in SR with IPv6 data pl= ane. Would you agree?


Regards,

Greg Mirsky


= Sr. S= tandardization Expert
=E9=A2=84=E7=A0=94=E6=A0=87= =E5=87=86=E9=83=A8/=E6=9C=89=E7=BA=BF=E7=A0=94=E7=A9=B6=E9=99=A2/=E6=9C=89= =E7=BA=BF=E4=BA=A7=E5=93=81=E7=BB=8F=E8=90=A5=E9=83=A8 Sta= ndard Preresearch Dept./Wireline Product R&D Institute/Wireline Product= Operation Division


<= td valign=3D"top" width=3D"100">
E: gregory.mirsky@ztetx.com
www.zt= e.com.cn
=
Original Mail
Sender:=C2=A0Yangfan(IPStandard)
CC:=C2=A0= spring;detnet@ietf.org;
Date:=C2=A02021/07/26 14:09
Subject:=C2=A0[Detnet] =E7=AD=94=E5= =A4=8D: IETF-111 SPRING presentation on sr-redundancy-protection
_______________________________________________
detnet=C2=A0maili= ng=C2=A0list
detnet= @ietf.org
https://www.ietf.org/mailman/listinfo/detnet

=

Hi Balazs,

<= span lang=3D"EN-US" style=3D"font-size:10.5pt;color:#1f497d">=C2=A0<= u>

Thank you for your comments.

As what Gyan mentioned during the presentation, this draft r= edefines redundancy protection as a general protection mechanism designed f= or SR network. Firstly, it is a general mechanism can be used in many uses= cases, not only DetNet use case. Secondly, it applies to SR network, not a= general IP or MPLS data plane solution which Detnet requires. Since the sc= ope is changed, I don=E2=80=99t think redundancy protection is necessary to= follow DetNet architecture.

If redundan= cy protection is not a DetNet mechanism, I don=E2=80=99t think it should co= ver both P2P and P2MP services.

We are ha= ppy to address the comments that relates to redundancy protection in next r= evision.

=C2=A0

<= p class=3D"MsoNormal">Thanks.

Fan

=C2=A0

=E5=8F=91=E4=BB=B6=E4=BA=BA: Bal=C3=A1zs Var= ga A [mailto:balazs.a.varga@ericsson.com]
=E5=8F=91=E9=80=81= =E6=97=B6=E9=97=B4: 2021=E5=B9=B47=E6=9C=8827=E6=97=A5 4:49
=E6= =94=B6=E4=BB=B6=E4=BA=BA: draft-geng-spring-sr-redundancy-protection@ietf.org<= /a>
=E6=8A=84=E9=80=81: spring <spring@ietf.org>; detnet@ietf.org
=E4=B8=BB=E9=A2=98= : IETF-111 SPRING= presentation on sr-redundancy-protection

=C2=A0<= /span>

Hi,

=C2=A0

As time not permitted co= mments during the SPRING meeting, major comments regarding the

redundancy protecti= on presentation:

https://= datatracker.ietf.org/meeting/111/materials/slides-111-spring-sr-for-redunda= ncy-protection-00

=C2=A0

1, General: despite the reference to DetNet this draft is no= t compliant with Figure 1 of RFC8655 (DetNet Architecture)

2, Slide-9: DetNet prov= ides both p2p and p2mp services. This draft only p2p, so many DetNet use ca= ses cannot be supported

3, Slide-9: there were many DetNet related comments on the= list. Only some were addressed in the latest version of the draft.<= u>

=C2=A0<= u>

Thanks & C= heers

B= ala=E2=80=99zs

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: Je= ffrey (Zhaohui) Zhang <zzhang@juniper.net>
Sent: Monday, July = 19, 2021 11:44 PM
To: Yangfan (IP Standard) <shirley.yangfan@h= uawei.com>; Bal=C3=A1zs Varga A <balazs.a.varga@ericsson.com>; draft-geng-spring-sr-redundancy-protection@ietf.org
Cc: spring <spring@ietf.org>; detnet@ietf.org
Subject: RE: SR and DetNet= , draft on sr-redundancy-protection

=C2=A0

Hi Fan,

=C2=A0=

Catching up on this late =E2=80=A6<= /u>

=C2=A0

= You said:

=C2=A0

= =C3=98=C2=A0 = Trigge= red by the discussions in SPRING, I think we can define redundancy segment = and merging segment as a functional segment without routing and topological= semantics, and use different segment for the routing purpose. Thus, redun= dancy segment and merging segment are segments with pure service semantics = and don=E2=80=99t violate the sub-layers definition in DetNet architecture.=

=C2=A0

Are you alluding to using replication segment for the routing/f= orwarding purpose? In my late response to an old email of yours that I just= sent (https://mailarchive.ietf.org/arch/msg/s= pring/YyEb8kGgtXxITZaIGyxynp9wh9s/), I also said =E2=80=9Cthe redundan= cy/merging functionality can be considered as an overlay service that makes= use of replication underlay service=E2=80=9D =E2=80=93 so maybe we=E2=80= =99re converging?

=C2=A0

Thanks.
Jeffrey

=C2=A0

From: spring <s= pring-bounces@ietf.org> On Behalf Of Yangfan (IP St= andard)
Sent: Saturday, June 12, 2021 2:07 AM
To: Bal=C3=A1zs Varga A <balazs.a.varga@ericsson.com>; draft-geng-spring-sr-redundancy-protection@ietf.org
= Cc: spring <spring@ietf.org>; detnet@ietf.org
Subject: [spring] =E7=AD=94=E5=A4=8D: SR and DetNet, draft on sr-redundancy-protection=

<= /u>=C2=A0

[External Email. Be cautious of content]

=C2=A0=

Hi Bala=E2=80=99zs,

<= p class=3D"MsoNormal">Thank you for your comments. Please see my reply inline starts wit= h Fan1>>

=C2=A0

=E5=8F=91=E4=BB=B6= =E4=BA=BA: = Bal=C3=A1zs Varga A [mailto:balazs.a.varga@ericsson.com] =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:= 2021=E5=B9=B46=E6=9C=8811=E6=97=A5 21:12
=E6=94=B6=E4=BB=B6=E4=BA=BA: draft-geng-sprin= g-sr-redundancy-protection@ietf.org
=E6=8A=84=E9=80= =81: detnet@ietf.org; spring <<= a href=3D"mailto:spring@ietf.org" target=3D"_blank">spring@ietf.org>=
=E4=B8=BB=E9=A2=98: SR and DetNet, draft on sr-redundancy-protection<= /u>

=C2=A0

Hi Authors,

=C2=A0

thanks for the update of your draft, to clarify the propose= d mechanism of

redundancy protection.

=C2=A0

I have concerns regarding this draft as (1) the SRv= 6 approach does not follow the

DetNet architecture, and (2) repeats functionalitie= s that are provided by the DetNet

service sub-layer but with serious limitations.<= u>

= =C2=A0

(1) Det= Net has defined two sub-layers: the service sub-layer and the forwarding=

sub-layer= . The service sub-layer is responsible for service protection and the

forwarding s= ub-layer provides forwarding paths and resource allocation on top of=

them for the = DetNet flows. DetNet specifications allow to use any technology in

the forwarding = sub-layer, including Segment Routing.

=C2=A0

The SRv6 approach described in "draft-g= eng-spring-sr-redundancy-protection" breaks

the clear concept of the sub-laye= rs by mixing them up. It contradicts to several

points at least to RFC8655 (DetNet= Architecture), RFC8938 (Data Plane Framework)

and RFC8964 (DetNet MPLS Data Plane= ).

=C2=A0

<= span lang=3D"EN-US" style=3D"font-size:10.5pt;color:#1f497d">Fan1>> S= egment routing extends IPv6 by introducing SRH extension header and SID pro= gramming. From the perspective of SID list in SRH, it provides the explicit= route to IPv6 data plane in forwarding sub-layer. From the perspective of= SID programming and Endpoint behaviors, it provides the packets replicatio= n and elimination in service sub-layer. So Redundancy segment could include= the routing characteristic and service indication at the same time. Simil= ar happens to Merging segment. I think this is why you called it breaking t= he concepts of two sub-layers and mixing them up.

<= p class=3D"MsoNormal">Triggered by the discussions in SPRING, I think we can define redu= ndancy segment and merging segment as a functional segment without routing = and topological semantics, and use different segment for the routing purpo= se. Thus, redundancy segment and merging segment are segments with pure ser= vice semantics and don=E2=80=99t violate the sub-layers definition in DetNe= t architecture.

Besides, in RFC8655 4.1= .2 DetNet data-plane overview, it says,

This separation of DetNet sub-layers, while helpful, should not = be considered a formal requirement. For example, some technologies may viol= ate these strict sub-layers and still be able to deliver a DetNet service<= /span>

I th= ink SRv6 could be acceptable based on this.

=C2=A0

In addition, I guess where to e= ncapsulate meta data could be one concern. According to DetNet, they should= be identified and encapsulated at SR edge node. We plan to include both p= ossibilities in next update. To carry them at SR edge node would be recomme= nded as the first choice, and thus does not violate DetNet architecture. Ri= ght now I still want to keep the possibility for redundancy segment to add = meta data for some corner case.

= =C2=A0

So far, I didn=E2=80=99t realize there = are other points contradict to DetNet RFCs. We are very happy to discuss th= em.

=C2=A0

(2) The motivation for "draft-ge= ng-spring-sr-redundancy-protection" is not clear especially<= /u>

as the SRv6 appro= ach seems to be repeating DetNet service sub-layer functionalities; however= ,

with = a limited set of functionalities without any clear benefits.<= /span>

Fan1>> as what I said in previous email to Joel, = redundancy protection comes from service protection specified in DetNet, bu= t more focus on how to do it when Segment Routing is introduced to MPLS an= d IPv6. Currently, DetNet defines IP and MPLS data planes for DetNet in RFC= 8939 and RFC8964. There is segment routing consideration in RFC8964, but no= t in RFC8939. In our draft, we try to focus on definition in SRv6, and for = MPLS-SR just obeys the specifications in RFC8964. It is clear that we are = not repeating DetNet service sub-layer functionality, but to fill the gap b= etween RFC8939 and SRv6. If WG thinks the SR-MPLS sections are redundant, w= e can take reference from RFC8964 for simplicity in next update.=

I don=E2=80=99t think there is no clear benefit wh= at segment routing brings to IP(v6). By using the redundancy protection mec= hanism, DetNet services running over SRv6 don=E2=80=99t rely on IP+UDP/TCP = tuple to provide PREOF. The authors believe this draft is meaningful.

Thank you for bring this topic into DetNet an= d SPRING. I take it as whether SRv6 is worth to be specified separately bes= ides the existing DetNet data plane RFCs. It is a valid and important ques= tion for DetNet, we may need some guide from the WG.

My 2 cents.

=C2=A0<= /u>

Best regards,

Fan=

=C2=A0

=C2=A0

Cheers

Bala'zs<= /u>

<= /u>=C2=A0

Juniper Business Us= e Only


_______________________________________________
detnet mailing list
detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet
--
--00000000000068f7ce05c8154009-- --00000000000068f7cf05c815400a Content-Type: image/jpeg; name="24242e5637af428891c4db731e7765ad.jpg" Content-Disposition: inline; filename="24242e5637af428891c4db731e7765ad.jpg" Content-Transfer-Encoding: base64 Content-ID: <17ae6aaf0e958b2e99d1> X-Attachment-Id: 17ae6aaf0e958b2e99d1 R0lGODlhcwAmAPcAAAAAAP///wCP1QCP1Pf7/vL5/QCP1gWR1gqT1gyU2AyU1w6V1xWY2BeZ2R6c 2iGd2iyi3C6j3TOl3Tqo3kWt4Emv4Uyw4U2x4lOz4ly35F645GO65WW75me85m6/53XC6IHH64XJ 64bK7IzM7I/N7JXQ7ZfR7pnS7pzT7p3U76PW8KPW76XX8K7b8bDc8rff87vh9Lzh9L7i9cnn9tLr +Nnu+eDx+uf0++n1++33/PD4/PT6/fj8/gKQ1AWR1QeS1QiT1QmT1g+W1xCW1xOX1xia2Bub2Ryb 2R+d2SCd2SKe2iSf2iag2ymh2yqh2yui3DSm3Tio3Typ3j2q3j6q3kCr30Os30eu4Euw4U6x4U+y 4k+y4VGz4lCy4Va141W04li241q341245F+55GW75Ga85Wm95mi95Gq+5Wu+5m2/5m/A53HB6HDA 53HB5nLB53PC53XC53bD53nE6HvF6X3G6X/H6YHI6oHI6YLI6oLI6YbK64TJ6YnL64rM64zM65HP 7JPQ7ZbR7ZrT7qXX76bY8KfY76jZ8Kra8azb8a/c8bDc8bHd8rLd8rXe8rXe8bjg87zi9Lzh873i 88Dj9MPl9cXm9cfm9cnn9c3p9s/q987p9tHr99Lr99Xt+Nbt+Nrv+d/x+eDx+eX0++Tz+u/4/OHy +ePz+ur2+/b7/fr9/vz+/v7//////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAK0ALAAAAABzACYA Rwj/AAMIHEiwoMGDCBMqXMiwoUOGiti0mUhxopcBAgZoHKAglcATFaVg3DgAC0U2hgKsKkJyiZqK FUV4bHijx4AHDFmN0BiJ4A2NRFYRJKAAo6WFKzJibOCQEclMB1WxxOgDUQEeqbKm2sEDoQaMhAqS sonE4B2MeQ7WmGlwj0YKCv0oHeDkIUGnAvJCNShVowA7dgXyyXKhsGEJG6kYNqxFUEImGSsQDJFR gOSClUj61cx5wAmEBKJk9JIwTefTaxzaGNnQxhIBex0WAUPwRZoOZnLr3q27Q6CBKXgL742mhUBW e3AP771HlcNSaDjQCVwwByQc1A2+9vtbodONsQn2/8UI2O6F03lP+/1QcEpeJgMbabwyMEzeOQuJ bBSAyC5ejeENNN5GQzBAxIEHNgAGAQZ9JQAlBvUggBIGlYDWQBtYoKGGW1yw4YZacPGhBVjsIRAB B4xEV3YCfZdRgAKNJ0ATLBo01gBlOXSIARgpohAEeQkgSo1EFmnkkUgmqeSSCKkxl3qaMRUBZ5V1 llcHAaQ40lxP+uXQWALkmB0HGplhECYHWADDQ24oJYAVClHilwCgRMVSXiYGhgIZG/TZZxlXaNTD F2X4+adxA+Fg0wBkEGTfACkQhNgAKzR0iop0MvQdgHZu5EdgXw0AYUE2UViQhQKkVdAcQZYSAA9D GP/xxQ4B1KHRFg1h4OYYDzHiJowBDKgiSZXlSZAGeYVFEJhiDnRHXnoM5EOXxO7HmQMGdRJkRtj5 txmwMqoRWBZPplftuXEkxIUJBj2CxUJSVPkGi5sOAO5UA6hqJCql2sVKEBilcRCyAxhQB0GFqEet X3IglAhJlxzEAwPoaSaABV+S1VAmQ+RlREOTBHkGkySXbPLJKKes8sosC6TJllCS9JshC8NsbSUB eFAzZ244FIpSNfrRxADsGoRKQS/ETCWWIShspSMBUGyteu82dGOzCr3AR0EyaESFQU4OAJdDcBC7 SEJjuJmuQTzg+0SSNmG7ECuQDZBAQUlo9AlBg2D/BMVDm2wpQA4KOUISJ53mpa9DJVRmLkZcUgv1 QDRjRMNAI2SUmkAzYDSEcw3xMVcEmj7VqUblPSRGRl2ooMIKK6hAh0Y/kMBC7K9PkBceBeGwUaUB gLKRc/xqZIpD7vkFR0Obwna6AGiAqlEhBY1iUxIG5YFRtAZh1IYOAh090AIY9cRQAUBALsBRzM91 734CICDEAvQvoMAQGNBaELICKDvQ1Wa5kEBi4IJGNMITmTCgAhvhgg8o5QsvMKALcHaQSKRHAAro SlO+ZafHQQ5mAuhDg8AiFo0VBAQCDAAIMWWuKlWGKQZJg5vg5C2/vI92LujKKna4CtAdRAwa8QIL 7YY4xLPErwREHGIVMMI7km0nL4CgjovsdboBiNAumbPYsKpkLUQZRAZ5+dtAOrEAAXwtITjgkiey U68bDiB1RSKARo4QmEOkR3wDOUNlMnCQQrgJPvQyHV+KUCwkAfAhYMjLD4RyECxUJhEESeRmBCAB mMCkBAlpnhsHwAQPWHIifWCQ1UzIEFAEqQsLwQEQ8gIBgWiBS0qbI0JeMJcaHGQV04plXr6kEbkp hBVTEkAPjtcQOWSEVwGQxBw+wMxmOvOZHxiEQnIAgj1o8JZ/gKY2SeDDhejgDW1YnEI+AUm7fIKR LUunOtfJThYFBAA7 --00000000000068f7cf05c815400a Content-Type: image/jpeg; name="9ae3e214c17d49ed935d87c674ba3ee2.jpg" Content-Disposition: inline; filename="9ae3e214c17d49ed935d87c674ba3ee2.jpg" Content-Transfer-Encoding: base64 Content-ID: <17ae6aaf0e9d7624e902> X-Attachment-Id: 17ae6aaf0e9d7624e902 R0lGODlhggB4AHcAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQICgAAACwAAAAAggB4AIcATr79vg2j x+twuSDo8tdNjNSk0mTQ57AojVB4uI7+1GPI3/P+6rKPxan9yjsBes4/gtD+34y61u9jm9rr9vva 7Pek0aolccv///8Baccki9Sj0FwSfM6DtOOAv2Wy1e9Mo92axurf78n9xisLacf+2XNwpN33+vE7 m9r9zkv+89Q0jNWMvebh7/nL5KPR5vbC3vP+5Jxks+NbpN10u+UDg9Gqzuyi0YLx9+aTvuYkhNF/ wDbZ7L0cjNQAdccAZMUlkta73Y0Ybsn+z1CUyk5LnNpiqd88k9f9whz+3YNNqt9EnNr0+/18vOaF weczm9oBjNQae879xzK426PV7fjc8vqIxCek0u79zEP+5qR8r+Cd0u5ss+O84vT+8Mlbqd8Le87M 6fdTnNrl8dMrg9G22e8BXcMKdMsrdcyUyuuMy+xtqd+s1vAsktb+9t3+1muy2Hqs1XTt+f1xsdvE 4/X9012BwQ3u9uIwjelDkteKxTTW6rr+23tTo939xCNEo91ro92DvPd7wOcchNKEwoQ8jNRtvOZN ltg8o90sm9qIvui02YOm0/kri9QLgM/m+f1dseIUg9EMjNQOZsZUqd8NW8I0k9cSdMv+4ZObzOwk fM/H6ff+6Ku24PN1wunV8frz+esyhNHN5quDvOZcnNrU6vczeM2bzVpxr+y/35R7viO73PLb7cOn 0mz++OTE4Z2s2vHj8/oSbsphpN6TyTwAbMmU0O6r05rb7vn9wRTN7PlDi9Ti8M1Dltj+7LvT6LRK ktaTxene+Pw3od2EyetbrOHL5fV0reAse86d2PF6vSlzteMCk9am2PEtldigz/Eckdaz1/Gt1IW6 3IRjreGz3PkBVMBNseEzltg8mOH9yC9sreFVrOBSltgcdMs9ltgkldmKwOdhueUeftAAddCMw+mB v+kNbcnn89ir0+6jzex6tOP90E/q9NyVyPBEqd7R56+k0nH9yTSz2/ILftB8w+mAvyP92G390VQK hNEBdMuEw+kAfdARftD+/v7///8I/wAxCBxIsKDBgwgTKlzIsKHDhxAJMimHAgaGckvoYNgHgg6T JktKMaFRpBSGZSBKyeECogIFLn1iYeDyxSW1LxRiFeMmh8kXarGq9KHGBNdPDLH6cImFC8QyDC9A 0MBABUQTJsaWNMFAZ8koDFn3MemyJBiGVX/SYJiHItNaFFsiLkwH4goTarXSYZihjw2GPvrSyQFx xiMKfRaPgFkV69slY7Es0aOCoVEkY1UaaYpValAkCnIG6SjVeQUFY5E0FAXTBtcmDnmYrHrwhKu+ IhTmnenDJJ0+EBg+1OJ9pdY2DMH0ycCQptayibW+ZvozT67BJrW4gFXXgusVmXS+c/9NR+HslfKr 0slMT0E2GyZr2bRf9YEJkw/RBKaLZj/aKgwUpFNdb/MwIUc6FgX4HwVX/BcLgkhd0QVS6mgUiw3G YICLOhnickWGpahTwUw1uGXdWcGU8kIaGp3o4oswMsSEEpKsUkoT1UVUzAMmxujjjz5SoUMtsFzx ADVyZfLFf0A26eRDxswTxhrArGJME/lBSUd5T3YZC3xdFtSUDuowBSYT8zC5EBMgaGBRmE3OM0sw XMKJQRP6RAemQKvkg8KeCTExgyUt2hkjE1xY0wguhlLRiD5PbFJQVto1xMSXhv54BQo01NnlRA/w eJB9Db3gUaY/XiqHobGAoI8zlBn/REEzOSokxiVZogrjKtzs4+mTqP0gw6oGrXJJHgzRgEKhup6I aAYrjAhnUhr4dVApXJi1UE6ANisXBcXU0kascFYhUqDdHmTMKr96CxEFkOiTCLldzgPJFQnFkkmu CYnhDb+6VlFPPYw6RMEXPzRi0kNXGMKsQhQYYY0l7fKpzxEMdSDGw6iyUUsGejnERDBkzCKTQ1UU Ys1xlqpDilgIlbJNOO5CtMouBXQRS8UHUdAJvQvF8skxppQD0SbEvkhHNDzbyUQYYawyAw0nF8QE FfPYUh0uIaRT1BZX0FF1QVfMEIwuW4q8yhqZpCtQLGlYq9Af+nxQ80Cj/KAP1QRV/wELSJHoA4S+ ZuiAyyj6PIANNVvoAmgzGphxBNBBI+zM2AStoo8lDIHEcbPzAFHLA50KVMoMD+SpzyW94ALDEUux EMUZqrehzkDz9FALGII0fVAslECK+UAVcGH03RGFro8+acQixxWa/NDDH4bYIilSq8YCSz3XgHPG D7MwQUEYooPBN0SxcKMPIr43tG77mc7TRiQg9EJDGKNQM0/SCDGhiyfcSFMf3gGNSPROLunTxzCG 97Z9MaQIl5Ab8qgShmVUQgfGIJVAVBCDJCShBAp4Ax8w4QWB2IcC67CGBmBxLgSqLxEMxEAZZIGs hYyiDxmaoOmoYIxllKNOWVCAA//8II8I4CMXSPADEkZQB04MZBViaB4V3MYQnfzAEjGsQBN6FCj4 xa8NjdgfmHyhgBH4YQQjkEcS+CCPETjAAW1EAj5KiJRYUIMM++DfQ9jQh2BQEQN/JAgd2BDDgP1h dLDYIB+kQEQ4ysMBUsBHDCJQhwjEoAR1SGMWTHiEH0Qikdapgh77tg98LaQIZ7Ab8iayPBnIxBUx wAIS5IEFB9QhCW9QQAmScA985DIFSYhAEmMgEHVEIgMgqEJEmHCFOVFRc5xbCAtmkcO7GaMNtYCV QDiByzfIEguYiEEddukANyoRCxHIAj4CMIJNMgESZwCDWt7VB2tgg2e4WAcXdZj/EDnsI3H7EIg6 bRmDN+AjAkI8IxbQSMs68OGhJXBAABzgBq4AIQN/oJxCZKPPQDZkFeK5G/B+0BoMeCEFSpRHCdLJ h1yMAB/4wEIJMBnOOsgDH5gogTxu6YqZZOCTEYmFRgcSi2CETCGHAeXd2ACCeSbBD1gYgjzkoYAy yuMenKCkF2KQgqrKAwkO4IMHIzACJ9JBDFxQ5kN00gs1GWQetYimQpoAgmq6KxZhUCsGFIAEEQ7x jG/AxBvekAIHYKKMSXRAYV+ahSTkogRvo0IVPEoQWOgjAzA7SPGOx0+FLIMDAcWAG/CBBD5koQ4p wIcCJimPRmKBD5eEIxZSIA8p/2BCmCmoaFZK4hCd1CISbjUIZcEyDy++qCcCkQMFllsFQFSCNwLh KxYGiwlOvAGODsBCLUeggDXyAR+0dAA7kmDVEqphEqaIhnJBAx8DYaAKm5AJBfZRA31Q4o8tCIYp bSWL2xlDHYxhQgX2EwtMuYgOf5ABBeighCcg4gnFUMcHCoWJJNIyBQ+VrXa164BcpCALb3CjTOvw RnkwAAO6SEMImoCIPyBiGGlgQibqwgXQrmR5PajVQVZBQ48GgxppuFIPuNEJY2QCGyCYxxWkdaIQ mOEMpQiBLDKgD73JQBgFeQMStjzR645gwxzuawzwoQ3tFvaN2tgkIGFBBr3V4v8HRfgEKczQhyWY YRmxEIMZejDPhFRgFLdb03rDAIstUQAX89CZgU9kjBlw4TTUWEIfvoCCfPRCx67IAghDSFgzErG1 KvUFJ1Lw5Vpmt5ybjMUyNJCIGdS5CJmQgzrEIKFyZGgV4VjFcD+aCeO6aGeRxUUskuGIWoSWIK5I thtU4AVu4mMEKSjBG9aYhDoQccMOWKIvuDIkQzCFCrho72QBOZDhtqAc+03IEs4QXF3RQQP6qIdD VJBV8mIBqhHgQznTmIKuVnQVjyJGkzSHAob82CP20WCmuqCBB8j7ISpAqRTayAdOhLAE+BArJgQC i4YLHEi42GJvq0ByybrbEvr/EEdEMHHGwmJBtZY0aApOjAE15AMMcanZKtJQigL7XFe4KMIPnlBI hPAhsQ7QhmIXGgAFDEQGP9CBjmN0uEAjVR/tRhUT1iGLPvhaIK7ggxmnasYA5KIOPRXIMkhQBL36 aB76+AZDylGMFyAvDPuYkHWCiIWpyoMdmEi7QIxhiHT7CBfm2Gf/9rRrH9knFlfw2omanQUGVLTc Si66ixSeEBikQWck/8S4DRXyfYTjHOMIg5OoEApjN94hVWeIGM7RNjkERfM+ioUMaqGDYjQCBbgP KggeIIkkD/xYDEkDFxamq1hA4gG1QAFkwkCHguXeGB7SQcIM/6JYqOGo6HLX/zpqUYsn6F0dOgBB 8BlysEbgKxxgEJdSdcWGclgfVZCoBTb0zoRRUPkqMbIPD/ADT0EBTQAGP3AEqhcjpbAMfZYQvVAL bRMUogcjuJAGnrAP+1APnjCBTfB5W6B3g4cNv5UGo2cdbDAI4sIkBsgBS+B2LgJXbcAQmXAMdGB7 VVCBCNQE1OAh8RcqeRIFXZAJP8ABzEcQufMAPQAC+mMdq+AM+pAP6TYrSrYN3BcR52Z1mRIGZ2AG mUAHRxAFGjCGUZAHhIYMCogQ9SAJoVJ+n6MQuLAEP0A66SIHS2ANS/B6LhINmbB+MTMPxrANVYIB m5AMsDAPsNAMGcIEzdAFVP/UBT1QA8xQAw/AWQ5RAUPiSj0zCrvAAnooJoDGECiQFy7SFP2QBnLw CJ84EMbQcFBQAzWgLQ0RC11AB2lwPqPyCauYObWAMQuRBpSwP0FRBX7IBP+UAQD4IojCAanTB0e4 EOWwG7sYERWwDzm3EDhIcroAg3B4GM6wgDAyXwn2jBs1CpWwAn4II5yHEPPQhyfSJw43jcJFVJgi B2pFASRXBbhAB13QBegGdB/IEIcgCwDzEFvwADUwfz8SC/vwBG3QNk0ABAXCBeCQCE/wBIPAAU4g j8lzDrGxEJmwDCZhe6vyeO1BRSMzOlMXI1XADWCQAT9ADVUADNZQDrHQCHr/szx6Yw7eoi+qtCZ0 0AlNYAlcUItXUARfMA/NwI0CMQ+RoE1N0gSpowFGoGuZAAgekQkz8AWGQAM04I6dZRDpsA/zUAXp sAyZIFl0MAq2ljajQgfkCCMVMIpPAAsncykmVGCgMUqZggvLIIvq1hcmxHgeFQtbIBhNEgYaQIDu sgevMAagwAup8As4gAOvkApjcAJj4AINQA7ZQINNEJcNoQ4/cAlZ5yIvcWnNcgKsEAcGIAKgsAdx 8Art0A5BAAesAAqsMA23EAwF6SSrUADdYHdNUgVhEAxr8B7pQAMDUw800AQZpA7Q+SKg8Au/wAt7 wAongAGg0A53IBB30A6g/8Cd7YADDpEOihAGBqJcfJkQxNglcpAHACADVXAEZrA8efIDo1AKoWAG AbWLr0AEogARVPCXDLEEtYCKOagLuthbadBrT9J/efAd20AGbXChjRAK6oALgFAIWzAPowCOEJEK qTCeD6EbNaQQ6nA/gMSeD5EJu3Oa6khUdFCj/Kie7yVUnTQVETEGvIBAaQB+geIsaaAPNSBBubcF LEJZYYBNxRARd+ACY2AdyDUX4XB/EJEJD5APK3lcMpAP+jAIlsiOPaAPlfIQonAKIiAXFbANY3oQ h3AOppRwL7qlXeoiVzAI/AAFm2NXBoEL8RIJircQe5AK7SAXq+CRDPEBNP9Qlgt6giCJkHd6IvtA D5L4AGE0V3lCCV+HAeFpHQ8ioxKxni7qEM2hDwoJI/PgijXQAzKQCUwpKGagASL4EHeQmXCSCTTA ZBFBB70gBrx6KGkwCOujBBwQBYjgCVtglzUHAgA2CqnaEL+wCFMaEaXwBV+xECQopBChC0OljDRg CQ3SCBlQC/oQCZqwDlWAAgAwA+3ZEC4QB9UKEXAnVwlxBSyApQ9BBTRgk0+CV/DRBSShA9DXdplA CuowjWPAAyaKPg7UEPZIjEHxrgWRCWZQC2/SJPi4J1ijBp6QI6pInQ3bJekwCl2Qg6JHBesHA2Iw A6L5IqNQCFr4JLzwCyP/6xAywwIMEYES9HrC8Ahdsg7IEAJ28gqtMK8PsQpnkKL3SjAncjh08q9U 0KkRcQBBcKhBdQWTKhEuAqOL8SSHxpEL0Q5I+y6UdQU0cIPD6IdFWgNbS6ng8Ax2wgoEYB3Xmq0K cQgkUHsk54dayqVPQgP54A5wkgpxgLXJcwa94FHpEAz66hB/+7Zy0Q434AFTcLM/0g6t8AonQgET 5jRpsKXV0CRjcApWYAWqEAeYS53YqZ2Gonzf+ou14AMWwAPfiQ6ikJu6eQDtcAJ3cAC5yZoHMKV3 8At7gAOgMAa/YAD2oAdEMAA7AA/tIAqQ+bt7MJ4iMLyeygPHiwFjIAo//xqblIkBv7ABQfCdLlIK lLAVC4GgtXd7+4oKcyANuBmbrXC17ZAKrZCbrHC/Y3AHrxAHooADrAAH1Dq9cKAHVkALp7ADypAK PNAKv9AOBTwNvADAAnwHIrAIi3DBomAALnCrixAHF2y1ZYuoDyB3CzEP5aC2OciU/RQLY8AK33kH PMALJxCZNOyprMALoJC8rHCod8AKsHkC7SACcKAMqkALqrADv2DDvYsDIsALOKCZQXwCBFzE7cAD vQsKIsAKVby635IOomo1dPoQL3AM65CODNEO8aAKdmAFiyDGYfmLInkiFlsLZTy5hIAACUDHE/QC s4C3gfmb7sMNS/EkjP+AB4FQxwVhLMDAEPUnEnJAkhDxCWxsMLhAsRNEAYUmIxT4CZ+wjVAyFJns EDDwAVSbKcvFECGwfIPZeGmQAWcguaG0C8jwhhNkDH9wpgkRp4acfEZqy9+yDD3oyHyytAyxCltw yhgQuWGyXLiQDi9bMwtGnOznOplQlhRABftBclQEzXASDEJwDMjsEOUAZHRgCJJwDfNgi+CACGyw BY/LBG0brUASDWLgFsLWWcZQBE+xEIeRBgumNcRYCsuKC6XAM5lAZXusjF9iDIVgBKu8wpAgA7Y8 G9jAENEQDM6saniGKsYQCjixClzgIGLzXl1QHlVwgxqSNvsIHzGNFFv/gA2hsgLVwUOmcyphkEEU wAYP/Wtd4Di6wgRwiQE0kAFfwQJkcDssgAx20QRkIAEnQQZ2sw6hoGt3lCGjwIyvaKYUsA2FMCJ9 UAjGIAeksAt2N1zBsA3YDBHBEAUzUNEvYtIawQIaigE5AAFeMwpTjQFYbTcdAAGrIAfbEApcHQUP 8IoPsAxhPdZ7kQcvIAcTAAyk0QfrIJDnQNUQYSAsMAmNELuZEgu6UB4UcC54lT1ThBRELVTtVdPL YwnVQdoCUQWrLcoYsAChMAMM0Y4Su1zOY0LEcik5QQflUCFq0AznfCLzQAkB1BC5ocsEoS/FUAwy IAPFwAVhQAHlwAUt/zARXyAD3AAEPxAFxLzcDNgH7KsQbPAH8bc80HcOTaALmmAG6RAGoZCT+nAG 0ofeqAIDUVAEDFEMZ9AGKJAIFgkNzqAebbIl3KDgT0AJmfC4/h2hdCCiCAFSKpuPuDBuTPE2uCBs dF3hEVGlMiK2JO4kuDALBVDNAxEMRzCzKa5DcTgIfooQTcABDzjj/LQuw1UBZWniPF4zsVAOo9Cp HOqJQ343jgIG0r1jF9ANJbnkWkcHkJEGTsDG+lJcmTAKMlFgtX0y75mjYS4Q/cwEY37mai4TRVEe V1MecoALbj61gLTah2badm7n4QYg49bN8BG2SLHnHx7oGFABK/CCMP9CBYWABmEQCzMw14JiBAU2 C8eBC0rBBC3QB45dCkWQ2f+c2Zx+Ff/8FavgFVyxBOUgG73gFmywBEQ7D9/QNumQB3qRCb1wO+rw Dfhi6/8RDL2QH8GwBAVSDr3A1d9gEaOwBDDQf0UQbtvwDS/QAt0wAxT+EBSQCUaDC2QQCrHwCBBQ CKWACxBQAFgxCLFRCqZwCLFAB8gwAWfhDWLAFWgw16uABoCAAVfgDfcuARewDc9zAR2AASHgDZmt Dt5wFSFwAWYxCt6gszngDak+ChcgABhwDN5wO1pw8UxwDGjwHzPgDVRtAt7gNYBgCgvABGIwDv9h e00yFqdSo/ZRo4BJVIsC0QUZNBaqRwFdoHo4DyCdYBKxYCM+Txk+A/TzQBmxMA+MkvQyUQVKjxTz 0PRRTxU6oyGdIBNYsyphUFxUXx6lwPWusYsBAQA7 --00000000000068f7cf05c815400a--