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: gregory.mir...@ztetx.com
www.zte.com.cn
Original Mail
Sender: Yangfan(IPStandard)
To: Balázs Varga A;draft-geng-spring-sr-redundancy-protect...@ietf.org;
CC: spring;det...@ietf.org;
Date: 2021/07/26 14:09
Subject: [Detnet] 答复: IETF-111 SPRING presentation on sr-redundancy-protection
_______________________________________________
detnet mailing list
det...@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 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:balazs.a.va...@ericsson.com]
发送时间: 2021年7月27日 4:49
收件人: draft-geng-spring-sr-redundancy-protect...@ietf.org
抄送: spring <spring@ietf.org>; det...@ietf.org
主题: IETF-111 SPRING presentation on sr-redundancy-protection
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 <zzh...@juniper.net>
Sent: Monday, July 19, 2021 11:44 PM
To: Yangfan (IP Standard) <shirley.yang...@huawei.com>; Balázs Varga A
<balazs.a.va...@ericsson.com>;
draft-geng-spring-sr-redundancy-protect...@ietf.org
Cc: spring <spring@ietf.org>; det...@ietf.org
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 <spring-boun...@ietf.org> On Behalf Of Yangfan (IP Standard)
Sent: Saturday, June 12, 2021 2:07 AM
To: Balázs Varga A <balazs.a.va...@ericsson.com>;
draft-geng-spring-sr-redundancy-protect...@ietf.org
Cc: spring <spring@ietf.org>; det...@ietf.org
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:balazs.a.va...@ericsson.com]
发送时间: 2021年6月11日 21:12
收件人: draft-geng-spring-sr-redundancy-protect...@ietf.org
抄送: det...@ietf.org; spring <spring@ietf.org>
主题: 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
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
