Subject: [Detnet] IETF-111 SPRING presentation on sr-redundancy-protection

From: Balázs Varga A <[email-masked]>
Date: Mon, 26 Jul 2021 20:48:33 +0000

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-for-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 some were addressed in the latest version of the draft.

Thanks & Cheers
Bala’zs

From: Jeffrey (Zhaohui) Zhang <[email-masked]>
Sent: Monday, July 19, 2021 11:44 PM
To: Yangfan (IP Standard) <[email-masked]>; Balázs Varga A <[email-masked]>; [email-masked]
Cc: spring <[email-masked]>; [email-masked]
Subject: RE: SR and DetNet, draft on sr-redundancy-protection

Hi Fan,

Catching up on this late …

You said:

  *   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 service semantics and don’t violate the sub-layers definition 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 “the redundancy/merging functionality can be considered as an overlay service that makes use of replication underlay service” – so maybe we’re converging?

Thanks.
Jeffrey

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Yangfan (IP Standard)
Sent: Saturday, June 12, 2021 2:07 AM
To: Balázs Varga A <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: spring <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [spring] 答复: SR and DetNet, draft on sr-redundancy-protection

[External Email. Be cautious of content]

Hi Bala’zs,
Thank you for your comments. Please see my reply inline starts with Fan1>>

发件人: Balázs Varga A [mailto:[email-masked]]
发送时间: 2021年6月11日 21:12
收件人: [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>; spring <[email-masked]<mailto:[email-masked]>>
主题: 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 and 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 at the same time. Similar happens to Merging segment. I think this is why you 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 service semantics and don’t 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 violate 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 edge 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 not violate DetNet architecture. Right now I still want to keep the possibility for redundancy segment to add meta data for some corner case.

So far, I didn’t realize there are other points contradict to DetNet RFCs. We are very happy to discuss them.

(2) The motivation for "draft-geng-spring-sr-redundancy-protection" is not 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 repeating DetNet service sub-layer functionality, but to fill the gap between RFC8939 and SRv6. If WG thinks the SR-MPLS sections are redundant, we can take reference from RFC8964 for simplicity in next update.
I don’t think there is no clear benefit what segment routing brings to IP(v6). By using the redundancy protection mechanism, DetNet services running over SRv6 don’t 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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 26 Jul 2021 21:03:51 +0000

Hello Bala’zs

Could you please be more specific on your item 1?

Regards,

Pascal

Le 26 juil. 2021 à 22:49, Balázs Varga A <balazs.a.varga=[email-masked]> a écrit :

Hi,

Thanks & Cheers
Bala’zs

Hi Fan,

You said:

Thanks.
Jeffrey

Hi Bala’zs,

Hi Authors,

Best regards,
Fan

Cheers
Bala'zs

_______________________________________________
detnet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet

---

From: "Yangfan (IP Standard)" <[email-masked]>
Date: Mon, 26 Jul 2021 21:08:30 +0000

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 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 scope is changed, I don’t think redundancy protection is necessary to follow DetNet architecture.
If redundancy protection is not a DetNet mechanism, I don’t think it should cover both P2P and P2MP services.
We are happy to address the comments that relates to redundancy protection in next revision.

Thanks.
Fan

发件人: Balázs Varga A [mailto:[email-masked]]
发送时间: 2021年7月27日 4:49
收件人: [email-masked]
抄送: spring <[email-masked]>; [email-masked]
主题: IETF-111 SPRING presentation on sr-redundancy-protection

Hi,

Thanks & Cheers
Bala’zs

From: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Sent: Monday, July 19, 2021 11:44 PM
To: Yangfan (IP Standard) <[email-masked]<mailto:[email-masked]>>; Balázs Varga A <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: spring <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: SR and DetNet, draft on sr-redundancy-protection

Hi Fan,

You said:

Ø  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 service semantics and don’t violate the sub-layers definition in DetNet architecture.

Thanks.
Jeffrey

Hi Bala’zs,

Hi Authors,

Best regards,
Fan

Cheers
Bala'zs

---

From: Balázs Varga A <[email-masked]>
Date: Mon, 26 Jul 2021 21:20:32 +0000

Hi Fan,

Thanks for your prompt reply.
I agree with your direction to redefine the target of this mechanism. In my view your draft was “inspired by DetNet” and
intends to improve the functionality of SR. That is absolutely fine. :--))

Please, make it clear in the draft as well, that would avoid any misinterpretations.

Thanks & Cheers
Bala’zs

From: Yangfan (IP Standard) <[email-masked]>
Sent: Monday, July 26, 2021 11:09 PM
To: Balázs Varga A <[email-masked]>; [email-masked]
Cc: spring <[email-masked]>; [email-masked]
Subject: 答复: IETF-111 SPRING presentation on sr-redundancy-protection

Hi Balazs,

Thanks.
Fan

发件人: Balázs Varga A [mailto:[email-masked]]
发送时间: 2021年7月27日 4:49
收件人: [email-masked]<mailto:[email-masked]>
抄送: spring <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
主题: IETF-111 SPRING presentation on sr-redundancy-protection

Hi,

Thanks & Cheers
Bala’zs

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 26 Jul 2021 21:22:34 +0000

Hello Fan,

It would be neat that the proposal can be used for DetNet and RAW.

 I trust that we can find a way to alleviate the issues that Bala’zs has raised and maintain the capabilities that you are after.

Regards,

Pascal

Le 26 juil. 2021 à 23:09, Yangfan (IP Standard) <[email-masked]> a écrit :

Hi Balazs,

Thanks.
Fan

Hi,

Thanks & Cheers
Bala’zs

Hi Fan,

You said:

Thanks.
Jeffrey

Hi Bala’zs,

Hi Authors,

Best regards,
Fan

Cheers
Bala'zs

---

From: <[email-masked]>
Date: Tue, 27 Jul 2021 12:16:06 +0800 (CST)

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 IPv6 data plane. Would you agree?

Regards,

Greg Mirsky

Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division

E: [email-masked] 
www.zte.com.cn

Original Mail

Sender: Yangfan(IPStandard)
To: Balázs Varga A;[email-masked];
CC: spring;[email-masked];
Date: 2021/07/26 14:09
Subject: [Detnet] 答复: IETF-111 SPRING presentation on sr-redundancy-protection

Hi Balazs,

 

Thanks.

Fan

 

Hi,

 

 

Thanks & Cheers

Bala’zs

 

 

 

 

Hi Fan,

 

You said:

 

 

Thanks.
 Jeffrey

From: spring <[email-masked]> On Behalf Of Yangfan (IP Standard)

 

Hi Bala’zs,

 

发件人: Balázs Varga A [mailto:[email-masked]] 
 发送时间: 2021年6月11日 21:12
 收件人: [email-masked]
 抄送: [email-masked]; spring <[email-masked]>
 主题: SR and DetNet, draft on sr-redundancy-protection

Hi Authors,

redundancy protection.

 

 

 

 

 

 

My 2 cents.

Best regards,

Fan

 

Cheers

Bala'zs

---

From: "Yangfan (IP Standard)" <[email-masked]>
Date: Tue, 27 Jul 2021 05:18:51 +0000

Hi Greg,

Thank you for your comments.
At present, this draft only focus on P2P service. The extension of Segments and SR policy is all P2P-based.
If there are interests from WG,  the authors welcome people to extend the capability of redundancy segment and merging segment to support P2MP services.
So far, the draft does not consider P2MP service and the authors would like to stick to current scope.

If I remembered correctly,  there were other expired drafts specifying DetNet in SRv6 data plane (e.g. draft-geng-detnet-dp-sol-srv6). If authors of those drafts want to proceed their drafts in future, I would be happy to contribute.

Regards,
Fan

发件人: detnet [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2021年7月27日 12:16
收件人: Yangfan (IP Standard) <[email-masked]>
抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Re: [Detnet] 答复: IETF-111 SPRING presentation on sr-redundancy-protection

Hi Fan,

Regards,

Greg Mirsky

E: [email-masked]<mailto:[email-masked]>
www.zte.com.cn<http://www.zte.com.cn/>

Original Mail
[email-masked]<mailto:[email-masked]>

Thanks.
Fan

Hi,

Thanks & Cheers
Bala’zs

Hi Fan,

Thanks.
Jeffrey

Hi Bala’zs,

Hi Authors,

Best regards,
Fan

Cheers
Bala'zs

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 27 Jul 2021 02:27:09 -0400

Hi Balázs

Very nicely put that the redundancy protection draft was inspired by DETNET
framework  to now provide extensions to improve the functionality of SR.

We will make that clear in the draft.

As for DETNET use case I think we can leave off the table for now and
update the draft accordingly.  After adoption we can investigate the
possibilities and of making the redundancy protection inclusive of DETNET.
I think the hurdle of P2MP and as that is out of scope today and as DETNET
to be an inclusive use case we would have to figure out P2MP which will be
challenging.

Kind Regards

Gyan
On Mon, Jul 26, 2021 at 5:20 PM Balázs Varga A <balazs.a.varga=
[email-masked]> wrote:

> I agree with your direction to redefine the target of this mechanism. In
> my view your draft was “inspired by DetNet” and
>
> *From:* Yangfan (IP Standard) <[email-masked]>
> *Sent:* Monday, July 26, 2021 11:09 PM
> *To:* Balázs Varga A <[email-masked]>;
> [email-masked]
> *Cc:* spring <[email-masked]>; [email-masked]
> *Subject:* 答复: IETF-111 SPRING presentation on sr-redundancy-protection
>
>
>
> Hi Balazs,
>
>
>
> 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 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 scope is
> changed, I don’t think redundancy protection is necessary to follow DetNet
> architecture.
>
> *发件人**:* Balázs Varga A [mailto:[email-masked]
> <[email-masked]>]
> *发送时间:* 2021年7月27日 4:49
> *收件人:* [email-masked]
> *抄送:* spring <[email-masked]>; [email-masked]
> *主题:* IETF-111 SPRING presentation on sr-redundancy-protection
>
>
>
> Hi,
>
>
>
> 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 some
> were addressed in the latest version of the draft.
>
>
>
> Thanks & Cheers
>
> Bala’zs
>
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 27 Jul 2021 02:47:52 -0400

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’s still possible when you think 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 <[email-masked]> 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 IPv6
> data plane. Would you agree?
>
>
> Regards,
>
> Greg Mirsky
>
>
> 预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D
> Institute/Wireline Product Operation Division
>
>
>
> *Sender: *Yangfan(IPStandard)
> *To: *Balázs Varga A;[email-masked];
> *CC: *spring;[email-masked];
> *Date: *2021/07/26 14:09
> *Subject: **[Detnet] 答复: IETF-111 SPRING presentation on
> sr-redundancy-protection*
> *发件人:* Balázs Varga A [mailto:[email-masked]]
> *发送时间:* 2021年7月27日 4:49
> *From:* Jeffrey (Zhaohui) Zhang <[email-masked]>
> *Sent:* Monday, July 19, 2021 11:44 PM
> *To:* Yangfan (IP Standard) <[email-masked]>; Balázs Varga A <
> [email-masked]>;
> *Subject:* RE: SR and DetNet, draft on sr-redundancy-protection
>
>
>
> Hi Fan,
>
>
>
> Ø  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 service semantics and don’t violate the sub-layers definition 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 “the redundancy/merging functionality can be considered as an
> overlay service that makes use of replication underlay service” – so maybe
> we’re converging?
>
>
>
> Thanks.
> Jeffrey
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Yangfan (IP
> Standard)
> *Sent:* Saturday, June 12, 2021 2:07 AM
> *Subject:* [spring] 答复: SR and DetNet, draft on sr-redundancy-protection
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Bala’zs,
>
> *发件人:* Balázs Varga A [mailto:[email-masked]
> *发送时间:* 2021年6月11日 21:12
> *抄送:* [email-masked]; spring <[email-masked]>
> *主题:* SR and DetNet, draft on sr-redundancy-protection
>
>
>
> Hi Authors,
>
>
>
> The SRv6 approach described in
> "draft-geng-spring-sr-redundancy-protection" breaks
>
> 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 at
> the same time. Similar happens to Merging segment. I think this is why you
> 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 service
> semantics and don’t violate the sub-layers definition in DetNet
> architecture.
>
> This separation of DetNet sub-layers, while helpful, should not be
> considered a formal requirement. For example, some technologies may violate
> these strict sub-layers and still be able to deliver a DetNet service
>
> In addition, I guess where to encapsulate meta data could be one concern.
> According to DetNet, they should be identified and encapsulated at SR edge
> 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 not
> violate DetNet architecture. Right now I still want to keep the possibility
> for redundancy segment to add meta data for some corner case.
>
>
>
> 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 repeating
> DetNet service sub-layer functionality, but to fill the gap between RFC8939
> and SRv6. If WG thinks the SR-MPLS sections are redundant, we can take
> reference from RFC8964 for simplicity in next update.
>
> I don’t think there is no clear benefit what segment routing brings to
> IP(v6). By using the redundancy protection mechanism, DetNet services
> running over SRv6 don’t 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
>
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*