Re: [Detnet] [spring] 答复: SR and DetNet, draft on sr-redundancy-protection

[Balázs Varga A <[e-mail]>]

Hi Gyan,

Thanks for sharing your view. Just two comments/clarifications:

1, Using SR:
Again, it was never a question that SR is a valuable tool to provide explicit routes for DetNet.
Adding a figure showing how encapsulation and SR-headers are changed along the path would
help a lot for further discussions.
Please note, that DetNet supports both P2P and P2MP flows.


2, IP & PREOF:
> Also the draft below provides a solution for SR-MPLS data plane but not for SRv6.
> https://datatracker.ietf.org/doc/html/draft-varga-detnet-ip-preof-00

Some clarifications would be useful here.
https://datatracker.ietf.org/doc/html/draft-varga-detnet-ip-preof-00 is for IP data plane.
This is explained, e.g., in the abstract:
   This document describes how DetNet IP data plane can support the
   Packet Replication, Elimination, and Ordering Functions (PREOF) based
   on [RFC9025<https://datatracker.ietf.org/doc/html/rfc9025>].

Note that RFC 9025 is part of DetNet IP data plane; it is UDP over IP.
This solution leverages MPLS header fields over UDP, but that does not make it MPLS data plane;
it is still IP data plane; actually, applicable both to IPv6 and IPv4.

A key aspect of this solution is that no new header fields are specified, i.e., it is available already,
both for IPv6 and IPv4.

SRv6 provides a routing technique for IPv6.

Therefore, SRv6 can provide routing for https://datatracker.ietf.org/doc/html/draft-varga-detnet-ip-preof-00
used in IPv6; nothing special needs to be done. In other words, SRv6 can provide the routing as part of DetNet
forwarding sublayer for PREOF service protection as per
https://datatracker.ietf.org/doc/html/draft-varga-detnet-ip-preof-00 operating in the DetNet service sublayer.

Thanks & Cheers
Bala’zs

From: Gyan Mishra <[e-mail]>
Sent: Tuesday, July 6, 2021 10:41 PM
To: Yangfan (IP Standard) <[e-mail]>
Cc: Balázs Varga A <[e-mail]>; [e-mail]; [e-mail]; spring <[e-mail]>
Subject: Re: [spring] 答复: SR and DetNet, draft on sr-redundancy-protection


Hi  Bala'zs

As one of the Co-authors with Fan on the issue raised related to duplication of effort of DETNET architecture service protection sub layer providing the PREOF, sequencing function for the PRF node replication function and PEF node elimination function, in the DETNET framework specification  RFC 8938.

RFC 8938 excerpt


4.3<https://datatracker.ietf.org/doc/html/rfc8938#section-4.3>.  Packet Replication, Elimination, and Ordering Functions (PREOF)



   The Controller Plane protocol solution required for managing the

   processing of PREOF is outside the scope of this document.  That

   said, it should be noted that the ability to determine, for a

   particular flow, optimal packet replication and elimination points in

   the DetNet domain requires explicit support.  There may be existing

   capabilities that can be used or extended -- for example, GMPLS end-

   to-end recovery [RFC4872<https://datatracker.ietf.org/doc/html/rfc4872>] and GMPLS segment recovery [RFC4873<https://datatracker.ietf.org/doc/html/rfc4873>].

I would like to note here that the DETNET framework is flexible and as far as the service protection sub layer and how the PEF and PRF are performed that other solutions such as this drafts redundancy protection can be used for service protection sub layer.

Also as far as service protection can use mechanisms that are outside of Detnet architecture for path protection for POF function.


3.5.1.3<https://datatracker.ietf.org/doc/html/rfc8938#section-3.5.1.3>.  Service Protection



   Service protection involves the use of multiple packet streams using

   multiple paths -- for example, 1+1 or 1:1 linear protection.  For

   DetNet, this primarily relates to packet replication and elimination

   capabilities.  MPLS offers a number of protection schemes.  MPLS

   hitless protection can be used to switch traffic to an already-

   established path in order to restore delivery rapidly after a

   failure.  Path changes, even in the case of failure recovery, can

   lead to the out-of-order delivery of data requiring POFs either

   within the DetNet service or at a high layer in the application

   traffic.  Establishment of new paths after a failure is out of scope

   for DetNet services.







Also RFC 9025 DETNET MPLS over UDP/IP centralized controller based model for PREOF, PRF and PEF functions and sequencing see excerpt from RFC 8938 below:



4.2<https://datatracker.ietf.org/doc/html/rfc8938#section-4.2>.  Generic Controller Plane Considerations



   This section covers control plane considerations that are independent

   of the data plane technology used for DetNet service delivery.



   While the management plane and the control plane are traditionally

   considered separately, from a data plane perspective, there is no

   practical difference based on the origin of flow-provisioning

   information, and the DetNet architecture [RFC8655<https://datatracker.ietf.org/doc/html/rfc8655>] refers to these collectively as the "Controller Plane".  This document therefore does

   not distinguish between information provided by distributed control

   plane protocols (e.g., RSVP-TE [RFC3209<https://datatracker.ietf.org/doc/html/rfc3209>] [RFC3473<https://datatracker.ietf.org/doc/html/rfc3473>]) or centralized

   network management mechanisms (e.g., RESTCONF [RFC8040<https://datatracker.ietf.org/doc/html/rfc8040>], YANG

   [RFC7950<https://datatracker.ietf.org/doc/html/rfc7950>], PCEP [PCECC<https://datatracker.ietf.org/doc/html/rfc8938#ref-PCECC>]), or any combination thereof.  Specific

   considerations and requirements for the DetNet Controller Plane are

   discussed in Section 4.1<https://datatracker.ietf.org/doc/html/rfc8938#section-4.1>.


Each respective data plane document also covers the control plane

   considerations for that technology.  For example, [RFC8939<https://datatracker.ietf.org/doc/html/rfc8939>] also

   covers IP control plane normative considerations, and [DetNet-MPLS<https://datatracker.ietf.org/doc/html/rfc8938#ref-DetNet-MPLS>]

   also covers MPLS control plane normative considerations.


From a centralized controller management perspective as far as instantiation of DETNET flow service protection sub layer over forwarding plane sub layer as you can see their is some overlap.

Your point is well taken that DETNET provides its own service protection sub layer for PREOF, however I think the DETNET framework is open to other solutions such as this redundancy protection draft to provide a service protection sub layer solution that is separate from the existing RFC 9025 solution.

Also the draft below provides a solution for SR-MPLS data plane but not for SRv6.

https://datatracker.ietf.org/doc/html/draft-varga-detnet-ip-preof-00


Kind Regards

Gyan


On Wed, Jun 23, 2021 at 9:21 AM Yangfan (IP Standard) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Bala‘zs,

Not only does SR facilitate explicit routes, several WG drafts also give examples on the service function providing to other areas.
https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-service-programming
https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-replication-segment
https://datatracker.ietf.org/doc/html/draft-ietf-spring-resource-aware-segments
so I understand by leveraging redundancy segment and merging segment to provide PRF and PEF to DetNet is natural and acceptable.

I see there is a DetNet solution for PRF and PEF in IP data plane, and thanks very much for submitting another contribution to elaborate the details.
Similar like draft IPv6-HbH-Options-for-DetNet, the intent of the draft is also to bring extra capabilities from IPv6 EHs to DetNet current IP+UDP solution, in order to extend and progress existing work.
Thanks for the discussion.

Fan


发件人: Balázs Varga A [mailto:[e-mail]<mailto:[e-mail]>]
发送时间: 2021年6月18日 23:16
收件人: Yangfan (IP Standard) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
抄送: [e-mail]<mailto:[e-mail]>; spring <[e-mail]<mailto:[e-mail]>>
主题: RE: SR and DetNet, draft on sr-redundancy-protection

Hi Fan,

Thank you for the clarifications. Now I see the intended behavior better.

It was never a question that SR is a valuable tool to provide explicit routes for DetNet. Of course,
that part is fully in-line with DetNet RFCs, which place those functionalities at the DetNet
forwarding sub-layer, which is the natural location for SR.

The concerns are about the functionalities that are provided by the DetNet service sub-layer. It
looks strange to me to repeat DetNet service sub-layer functionalities by a tool that is naturally
for the DetNet forwarding sub-layer, in particular by SR in this case.

Note at the first place, that DetNet relay nodes are the ones that are capable to perform DetNet
service sub-layer functions. DetNet relay nodes need to perform DetNet flow identification at the
first place, which is based on 6-tuple in the case of IP data plane. Furthermore, DetNet already
includes an IP data plane that provides sequence number for PREOF as specified by RFC 9025. A
contribution has been submitted to describe how to leverage that for PREOF:
https://datatracker.ietf.org/doc/draft-varga-detnet-ip-preof/.

This all can be supported by SR with explicit routes in the natural way SR has been designed, just
like any other type of traffic on top of SR, not only DetNet. Nothing DetNet specific needed from
SR. That is, this is also fully in-line with SR today, not only DetNet.

Thanks
Bala'zs





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

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

发件人: Balázs Varga A [mailto:[e-mail]]
发送时间: 2021年6月11日 21:12
收件人: [e-mail]<mailto:[e-mail]>
抄送: [e-mail]<mailto:[e-mail]>; spring <[e-mail]<mailto:[e-mail]>>
主题: 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
_______________________________________________
spring mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spring
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347