Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Mengxiao.Chen]

Hi,

I support the adoption of this draft.
It proposes a source-routing-based mechanism of egress protection. It is not 
dependent on control plane protocols, and it is easy to deploy.

Thanks,
Mengxiao

From: rtgwg  On Behalf Of Yingzhen Qu
Sent: Saturday, February 10, 2024 3:30 AM
To: RTGWG ; spring@ietf.org; rtgwg-chairs 
; draft-cheng-rtgwg-srv6-multihome-egress-protection 

Subject: WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection 
(02/09/24 - 02/24/24)


Hi,



This email begins a 2 week WG adoption poll for the following draft:

draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress Protection 
in Multi-homed scenario 
(ietf.org)



Please review the document and indicate your support or objections by Feb 24th, 
2024.

Please note that there is an existing WG 
document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
Protection
 Which proposes fast protections for the egress node and link of an SRv6 path 
through extending IGP and using Mirror SID. As you discuss adopting 
draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:

·  Do we need these different solutions?

·  Technical merits and drawbacks of each solution

·  If there is any implementation of the proposals, please voice it.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.

Also copying SPRING WG.

Thanks,

Yingzhen (RTGWG Co-chair)

-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Lihao]

Hi WG:

I support the adoption of this draft.

Regarding the need for different solutions, I believe it is necessary to 
provide different solutions based on the capabilities of devices or chips, as 
well as different application scenarios.
Looking forward to the authors explaining the advantages and disadvantages of 
the proposed solutions, as well as their applicability to different scenarios.

Best Wishes.

Lihao.

From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Yingzhen Qu
Sent: Saturday, February 10, 2024 3:30 AM
To: RTGWG ; spring@ietf.org; rtgwg-chairs 
; draft-cheng-rtgwg-srv6-multihome-egress-protection 

Subject: WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection 
(02/09/24 - 02/24/24)


Hi,



This email begins a 2 week WG adoption poll for the following draft:

draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress Protection 
in Multi-homed scenario 
(ietf.org)



Please review the document and indicate your support or objections by Feb 24th, 
2024.

Please note that there is an existing WG 
document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
Protection
 Which proposes fast protections for the egress node and link of an SRv6 path 
through extending IGP and using Mirror SID. As you discuss adopting 
draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:

· Do we need these different solutions?

· Technical merits and drawbacks of each solution

· If there is any implementation of the proposals, please voice it.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.

Also copying SPRING WG.

Thanks,

Yingzhen (RTGWG Co-chair)

-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Feng Yang]

Hi,

Support.

This is a simple, fast, verified solution for tail end protection.

在 2024-02-10 03:30, Yingzhen Qu 写道:
Hi, This email begins a 2 week WG adoption poll for the following 
draft: draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 
Egress Protection in Multi-homed scenario (ietf.org) 
 
Please review the document and indicate your support or objections by 
Feb 24th, 2024.
Please note that there is an existing WG 
document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
Protection 
 
Which proposes fast protections for the egress node and link of an 
SRv6 path through extending IGP and using Mirror SID. As you discuss 
adopting draft-cheng-rtgwg-srv6-multihome-egress-protection, please 
also consider:


  * Do we need these different solutions?
  * Technical merits and drawbacks of each solution
  * If there is any implementation of the proposals, please voice it.
Authors, please respond to the list indicating whether you are aware 
of any IPR that applies to the draft.

Also copying SPRING WG.
Thanks, Yingzhen (RTGWG Co-chair)

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring


--
BR,
Feng Yang （杨锋）
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Yingzhen Qu]

Hi,

You mentioned "verified solution", are you aware of any implementation or
deployment?

Thanks,
Yingzhen

On Sun, Feb 18, 2024 at 12:35 AM Feng Yang  wrote:

> Hi,
>
> Support.
>
> This is a simple, fast, verified solution for tail end protection.
> 在 2024-02-10 03:30, Yingzhen Qu 写道:
>
> Hi,
>
> This email begins a 2 week WG adoption poll for the following 
> draft:draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress 
> Protection in Multi-homed scenario (ietf.org) 
> 
>
> Please review the document and indicate your support or objections by Feb 
> 24th, 2024.
>
> Please note that there is an existing WG 
> document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
> Protection 
>  
> Which proposes fast protections for the egress node and link of an SRv6 path 
> through extending IGP and using Mirror SID. As you discuss adopting 
> draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:
>
>
>- Do we need these different solutions?
>- Technical merits and drawbacks of each solution
>- If there is any implementation of the proposals, please voice it.
>
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to the draft.
>
> Also copying SPRING WG.
>
> Thanks,
> Yingzhen (RTGWG Co-chair)
>
>
> ___
> spring mailing listspring@ietf.orghttps://www.ietf.org/mailman/listinfo/spring
>
> --
> BR,
> Feng Yang （杨锋）
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Huzhibo]

Hi：

As a co-author of this two deafts.

·  Do we need these different solutions?

YES，draft-ietf-rtgwg-srv6-egress-protection-16 manually plan active/standby 
and VPN protection relationships. Data packet needs to carry only one VPN SID. 
It is applicable to scenarios where CE multi-homing is normalized and easy to 
plan.

  draft-cheng-rtgwg-srv6-multihome-egress-protection-05 
automatically calculates active/standby VPN protection relationships based on 
the primary and secondary VPN SIDs carried by the data plane. It is applicable 
to the scenario where the CE multi-homing relationship is complex.

·  Technical merits and drawbacks of each solution

  draft-ietf-rtgwg-srv6-egress-protection-16 features low SRv6 
encapsulation overhead, but requires manual planning of SRv6 protection 
relationships.

 Advantages of 
draft-cheng-rtgwg-srv6-multihome-egress-protection-05: The SRv6 protection 
relationship is automatically generated. No manual planning is 
required.Disadvantages: An extra VPN SID needs to be encapsulated on the data 
plane.，SRv6 Best Effort scenario SRH encapsulation is required.
 I support the adoption of this draft as a co-author .



Thanks

Zhibo



From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Yingzhen Qu
Sent: Saturday, February 10, 2024 3:30 AM
To: RTGWG ; spring@ietf.org; rtgwg-chairs 
; draft-cheng-rtgwg-srv6-multihome-egress-protection 

Subject: WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection 
(02/09/24 - 02/24/24)


Hi,



This email begins a 2 week WG adoption poll for the following draft:

draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress Protection 
in Multi-homed scenario 
(ietf.org)



Please review the document and indicate your support or objections by Feb 24th, 
2024.

Please note that there is an existing WG 
document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
Protection
 Which proposes fast protections for the egress node and link of an SRv6 path 
through extending IGP and using Mirror SID. As you discuss adopting 
draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:

· Do we need these different solutions?

· Technical merits and drawbacks of each solution

· If there is any implementation of the proposals, please voice it.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.

Also copying SPRING WG.

Thanks,

Yingzhen (RTGWG Co-chair)
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[linchangwang]

Hi：

   I support the adoption of this draft as a co-author .
I am not aware of any  IPR relevant to this draft.

The replies to several questions are as follows:

••  Do we need these different solutions?

Yes, [draft-cheng-rtgwg-srv6-multihome-egress-protection-05] is suitable 
for scenarios where the ingress node can arrange primary and backup SIDs based 
on the idea of source routing.

••  Technical merits and drawbacks of each solution

【draft-ietf-rtgwg-srv6-egress-protection-16】: Requires control plane extension 
and Mirror sid extension, does not require ingress node awareness.

 【draft-cheng-rtgwg-srv6-multihome-egress-protection-05】: Does not require 
control plane extension, requires  ingress node to include the backup service 
SID in the encoding.

3.I If there is any implementation of the proposals, please voice it.

   H3C has implemented the egress protection method as mentioned in the 
draft document "draft-cheng-rtgwg-srv6-multihome-egress-protection-05".

Organization: New H3C Technologies.

Maturity Level: Beta

Version: draft-cheng-rtgwg-srv6-multihome-egress-protection-05



Thanks,

Changwang


From: Yingzhen Qu [mailto:yingzhen.i...@gmail.com]
Sent: Saturday, February 10, 2024 3:30 AM
To: RTGWG; spring@ietf.org; rtgwg-chairs; 
draft-cheng-rtgwg-srv6-multihome-egress-protection
Subject: WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection 
(02/09/24 - 02/24/24)


Hi,



This email begins a 2 week WG adoption poll for the following draft:

draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress Protection 
in Multi-homed scenario 
(ietf.org)



Please review the document and indicate your support or objections by Feb 24th, 
2024.

Please note that there is an existing WG 
document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
Protection
 Which proposes fast protections for the egress node and link of an SRv6 path 
through extending IGP and using Mirror SID. As you discuss adopting 
draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:

· Do we need these different solutions?

· Technical merits and drawbacks of each solution

· If there is any implementation of the proposals, please voice it.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.

Also copying SPRING WG.

Thanks,

Yingzhen (RTGWG Co-chair)

-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[王亚蓉]

Hi wg, 
This document addresses the issue of egress protection from the forwarding 
perspective based on source routing, making it easier to deploy. 
I support adoption. 

Thanks, 
Yarong 

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[王亚蓉]

Hi wg, 
This document addresses the issue of egress protection from the forwarding 
perspective based on source routing, making it easier to deploy. 
I support adoption. 

Thanks, 
Yarong 

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[chen.ran]

Hi Yingzhen & WG，

I support the adoption of this draft.
It introduces a simplified protection mechanism for the SRv6 egress node，and 
ZTE has completed the prototype verification of 
draft-cheng-rtgwg-srv6-multihome-egress-protection-05.

Best Regards，
Ran


Original


From: YingzhenQu 
To: RTGWG ;spring@ietf.org ;rtgwg-chairs 
;draft-cheng-rtgwg-srv6-multihome-egress-protection 
;
Date: 2024年02月10日 03:31
Subject: [spring] WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring







Hi, This email begins a 2 week WG adoption poll for the following draft: 
draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress Protection 
in Multi-homed scenario (ietf.org) Please review the document and indicate your 
support or objections by Feb 24th, 2024.Please note that there is an existing 
WG document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
Protection Which proposes fast protections for the egress node and link of an 
SRv6 path through extending IGP and using Mirror SID. As you discuss adopting 
draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:Do we 
need these different solutions?

Technical merits and drawbacks of each solution

If there is any implementation of the proposals, please voice it.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.Also copying SPRING WG.Thanks, Yingzhen (RTGWG 
Co-chair)___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Qiuyuanxiang]

Hi WG,

As a co-author, I support the WG adoption, and I am not aware of any IPR that 
applies to the draft.

· Do we need these different solutions?

 This document [draft-cheng-rtgwg-srv6-multihome-egress-protection] introduces 
a simplified multi-homing egress protection method.



· Technical merits and drawbacks of each solution
[draft-ietf-rtgwg-srv6-egress-protection] is relatively more complex. It needs 
to configure Mirror SID for the protected egress node on the backup egress 
node, extend the control plane to distribute the mirror relationship through 
IGP or BGP, and maintain mapping entries.
[draft-cheng-rtgwg-srv6-multihome-egress-protection] just arranges the 
calculated SIDs of the primary and backup egress node in the SID list at the 
head node, and fast path switching can be achieved.


· If there is any implementation of the proposals, please voice it.

H3C has implemented the egress protection method described in 
[draft-cheng-rtgwg-srv6-multihome-egress-protection-05].

Thanks!
Yuanxiang


From: Yingzhen Qu 
Sent: Saturday, February 10, 2024 3:30 AM
To: RTGWG ; spring@ietf.org; rtgwg-chairs 
; draft-cheng-rtgwg-srv6-multihome-egress-protection 

Subject: WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection 
(02/09/24 - 02/24/24)


Hi,



This email begins a 2 week WG adoption poll for the following draft:

draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress Protection 
in Multi-homed scenario 
(ietf.org)



Please review the document and indicate your support or objections by Feb 24th, 
2024.

Please note that there is an existing WG 
document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
Protection
 Which proposes fast protections for the egress node and link of an SRv6 path 
through extending IGP and using Mirror SID. As you discuss adopting 
draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:

· Do we need these different solutions?

· Technical merits and drawbacks of each solution

· If there is any implementation of the proposals, please voice it.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.

Also copying SPRING WG.

Thanks,

Yingzhen (RTGWG Co-chair)

-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Feng Yang]

Hi Yingzhen,

The verified solution here I stated based on the lab test of several 
routers, e.g. H3C, ZTE.


在 2024-02-19 07:45, Yingzhen Qu 写道:

Hi,

You mentioned "verified solution", are you aware of any implementation 
or deployment?


Thanks,
Yingzhen

On Sun, Feb 18, 2024 at 12:35 AM Feng Yang  
wrote:


Hi,

Support.

This is a simple, fast, verified solution for tail end protection.

在 2024-02-10 03:30, Yingzhen Qu 写道:

Hi, This email begins a 2 week WG adoption poll for the following
draft: draft-cheng-rtgwg-srv6-multihome-egress-protection-05 -
SRv6 Egress Protection in Multi-homed scenario (ietf.org)


Please review the document and indicate your support or
objections by Feb 24th, 2024.
Please note that there is an existing WG
document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path
Egress Protection

Which proposes fast protections for the egress node and link of
an SRv6 path through extending IGP and using Mirror SID. As you
discuss adopting
draft-cheng-rtgwg-srv6-multihome-egress-protection, please also
consider:

  * Do we need these different solutions?
  * Technical merits and drawbacks of each solution
  * If there is any implementation of the proposals, please voice it.
Authors, please respond to the list indicating whether you are
aware of any IPR that applies to the draft.
Also copying SPRING WG.
Thanks, Yingzhen (RTGWG Co-chair)

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring


-- 
BR,

Feng Yang （杨锋）

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring


--
BR,
Feng Yang （杨锋）
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[高芳]

Hi 



I read the drafts and my understanding is as follows:

·Technical merits and drawbacks of each solution

draft-ietf-rtgwg-srv6-egress-protection-16

- a table/space/process is required to store and learn the mapping info between 
Remote-VPN-SID and VPN;

- function on forwarding plane is easy to achieve

draft-cheng-rtgwg-srv6-multihome-egress-protection-05

- A new flavor，provide a clean and more fundamental design/solution on  the 
forwarding plane capabilities;

-statically setting for the primary/backup relationship is not mandatory.




·Do we need these different solutions?

  Yes, i think these two do not provide an alternative solution, when 
considering the existence of network with different scale and device with 
different capability.

 

I support the adoption, with take the similar point of view to Li Hao




B.R

Fang Gao



| |
gaofang
|
|
gaof...@zgclab.edu.cn
|
 Replied Message 
| From | Feng Yang |
| Date | 2/19/2024 16:51 |
| To |  |
| Subject | Re: [spring] WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24) |

Hi Yingzhen,

The verified solution here I stated based on the lab test of several routers, 
e.g. H3C, ZTE.


在 2024-02-19 07:45, Yingzhen Qu 写道:

Hi,


You mentioned "verified solution", are you aware of any implementation or 
deployment?


Thanks,
Yingzhen 


On Sun, Feb 18, 2024 at 12:35 AM Feng Yang  wrote:


Hi,


Support. 

This is a simple, fast, verified solution for tail end protection.


在 2024-02-10 03:30, Yingzhen Qu 写道:

Hi,

This email begins a 2 week WG adoption poll for the following draft: 
draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress Protection 
in Multi-homed scenario (ietf.org) Please review the document and indicate your 
support or objections by Feb 24th, 2024.
Please note that there is an existing WG 
document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
Protection Which proposes fast protections for the egress node and link of an 
SRv6 path through extending IGP and using Mirror SID. As you discuss adopting 
draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:
Do we need these different solutions?
Technical merits and drawbacks of each solution
If there is any implementation of the proposals, please voice it.
Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.
Also copying SPRING WG.
Thanks,
Yingzhen (RTGWG Co-chair)


___
spring mailing list spring@ietf.orghttps://www.ietf.org/mailman/listinfo/spring
-- 
BR,
Feng Yang （杨锋）
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring



___
spring mailing list spring@ietf.orghttps://www.ietf.org/mailman/listinfo/spring
-- 
BR,
Feng Yang （杨锋）___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[allan michael]

Hi WG,

I support this adoption.

Here are my answers to the questions:

1. Yes. 2. The solutions mentioned in this draft [
draft-cheng-rtgwg-srv6-multihome-egress-protection
]are
simpler and can be more easily deployed in existing networks. By leveraging
programmable source routing techniques to include backup SIDs for egress
nodes, efficient egress protection can be achieved.




Thanks,
Allen

From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Yingzhen Qu Sent:
Saturday, February 10, 2024 3:30 AM To: RTGWG 
<>; spring@ietf.org; rtgwg-chairs
 <>;
draft-cheng-rtgwg-srv6-multihome-egress-protection

<>
Subject: WG Adoption Call -
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)
Hi, This email begins a 2 week WG adoption poll for the following draft:
draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress
Protection in Multi-homed scenario (
ietf.org)

Please review the document and indicate your support or objections by Feb
24th, 2024. Please note that there is an existing WG
document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress
Protection

Which proposes fast protections for the egress node and link of an SRv6
path through extending IGP and using Mirror SID. As you discuss adopting
draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider: ·
Do we need these different solutions? · Technical merits and drawbacks of
each solution · If there is any implementation of the proposals, please
voice it. Authors, please respond to the list indicating whether you are
aware of any IPR that applies to the draft. Also copying SPRING WG. Thanks,
Yingzhen (RTGWG Co-chair)
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[戴锦友]

Hi All:
I support the adoption of this draft.
Best regards!
 



David Dai
Fiberhome Technologies/CICT
Addr: Gaoxin Road 6#, Wuhan, Hubei, China
Tel:  +86 27-87693442-8318
MObile: +86 15377065812
Fax:  +86 27-87693784
E-mail: d...@fiberhome.com
From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Yingzhen Qu
Sent: Saturday, February 10, 2024 3:30 AM
To: RTGWG ; spring@ietf.org; rtgwg-chairs 
; draft-cheng-rtgwg-srv6-multihome-egress-protection 

Subject: WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection 
(02/09/24 - 02/24/24)
 
Hi, This email begins a 2 week WG adoption poll for the following 
draft:draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress 
Protection in Multi-homed scenario (ietf.org) Please review the document and 
indicate your support or objections by Feb 24th, 2024.Please note that there is 
an existing WG document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path 
Egress Protection Which proposes fast protections for the egress node and link 
of an SRv6 path through extending IGP and using Mirror SID. As you discuss 
adopting draft-cheng-rtgwg-srv6-multihome-egress-protection, please also 
consider:· Do we need these different solutions?· Technical 
merits and drawbacks of each solution· If there is any implementation 
of the proposals, please voice it.Authors, please respond to the list 
indicating whether you are aware of any IPR that applies to the draft.Also 
copying SPRING WG.Thanks,Yingzhen (RTGWG Co-chair)
-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, 
which is 
intended only for the person or entity whose address is listed above. Any use 
of the 
information contained herein in any way (including, but not limited to, total 
or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender 
by phone or email immediately and delete it!___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Chongfeng Xie]

Hi folks，
I support the adoption of this draft. 

Best regards
Chongfeng

From: Yingzhen Qu
Date: 2024-02-10 03:30
To: RTGWG; spring; rtgwg-chairs; 
draft-cheng-rtgwg-srv6-multihome-egress-protection
Subject: WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection 
(02/09/24 - 02/24/24)
Hi,
This email begins a 2 week WG adoption poll for the following draft:
draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress Protection 
in Multi-homed scenario (ietf.org)
Please review the document and indicate your support or objections by Feb 24th, 
2024.Please note that there is an existing WG 
document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
Protection Which proposes fast protections for the egress node and link of an 
SRv6 path through extending IGP and using Mirror SID. As you discuss adopting 
draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:
Do we need these different solutions?
Technical merits and drawbacks of each solution
If there is any implementation of the proposals, please voice it.
Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.Also copying SPRING WG.Thanks,
Yingzhen (RTGWG Co-chair)
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Peng Liu]

Hi, 

I support the adoption. 

Regards,
Peng


liupeng...@chinamobile.com
 
From: Yingzhen Qu
Date: 2024-02-10 03:30
To: RTGWG; spring; rtgwg-chairs; 
draft-cheng-rtgwg-srv6-multihome-egress-protection
Subject: WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection 
(02/09/24 - 02/24/24)
Hi,
This email begins a 2 week WG adoption poll for the following draft:
draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress Protection 
in Multi-homed scenario (ietf.org)
Please review the document and indicate your support or objections by Feb 24th, 
2024.Please note that there is an existing WG 
document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
Protection Which proposes fast protections for the egress node and link of an 
SRv6 path through extending IGP and using Mirror SID. As you discuss adopting 
draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:
Do we need these different solutions?
Technical merits and drawbacks of each solution
If there is any implementation of the proposals, please voice it.
Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.Also copying SPRING WG.Thanks,
Yingzhen (RTGWG Co-chair)
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[梁艳荣]

Hi Yingzhen & WG，

 I support the adoption of this draft.  
[draft-cheng-rtgwg-srv6-multihome-egress-protection-05] is easy to implement, 
and it's simple to deploy.
The replies to several questions are as follows: 
•  Do we need these different solutions?
 Yes. They are suitable for different scenarios.     
•  Technical merits and drawbacks of each solution.
    【draft-ietf-rtgwg-srv6-egress-protection-16】: Requires control plane 
extension and Mirror SID extension, does not require ingress node awareness.
    【draft-cheng-rtgwg-srv6-multihome-egress-protection-05】: 
      Drawbacks: Due to backup SID as SL [0], implementing this solution 
may affect the actual support capability of MSD (maximum SID depth), but this 
impact may be ignored when supporting SRH compression.           
      Merits: The backup egress PE is determined based on the routing 
optimization strategy and can be dynamically adjusted according to topology 
changes. So it's more flexible.
•  If there is any implementation of the proposals, please voice it.
    Ruijie Networks has completed a simple prototype verification of egress 
protection forwarding processes for 
draft-cheng-rtgwg-srv6-multihome-egress-protection-05.

Best Wishes,
Yanrong

Original

From: rtgwg <> On Behalf 
Of Yingzhen Qu
Sent: Saturday, February 10, 2024 3:30 AM
To: RTGWG <>; spring@ietf.org; 
rtgwg-chairs <>; 
draft-cheng-rtgwg-srv6-multihome-egress-protection 
<>
Subject: WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection 
(02/09/24 - 02/24/24)


Hi,



This email begins a 2 week WG adoption poll for the following draft:

draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress Protection 
in Multi-homed scenario 
(ietf.org)



Please review the document and indicate your support or objections by Feb 24th, 
2024.

Please note that there is an existing WG 
document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
Protection
 Which proposes fast protections for the egress node and link of an SRv6 path 
through extending IGP and using Mirror SID. As you discuss adopting 
draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:

·  Do we need these different solutions?

·  Technical merits and drawbacks of each solution

·  If there is any implementation of the proposals, please voice it.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.

Also copying SPRING WG.

Thanks,

Yingzhen (RTGWG Co-chair)___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Ketan Talaulikar]

Hi Yingzhen/All,

I have some concerns regarding the adoption of this document.


   - Do we need these different solutions?

KT> No. There is one common author for both these drafts who is also from a
vendor. I hope that person is also able to evaluate implementation aspects
and pick one solution.
KT> Does the adoption of this solution make the other draft "dead"?

   - Technical merits and drawbacks of each solution

KT> The existing WG draft needs IGP protocol extensions and its
implementation is very complex (as stated in the document under adoption).

   - If there is any implementation of the proposals, please voice it.

KT> I think this is the key question and look forward to the answer.

Coming to this document, please find below my comments/concerns:

1) There is no pseudocode for the new VPN behavior with PSD that covers the
entire behavior - i.e., one that covers not just the "normal" case but the
failure scenarios as well (e.g., PE/CE link failure).
2) The draft requires a transit IPv6 node to perform SRH processing for the
SID that does not belong to it (this is some action that a P router needs
to do when reachability to the PE is lost) and hence does not know what
that SID behavior is. This is something very new for SRv6 and it can cause
problems. e.g., consider the case that the active segment points to a BSID
- what happens when a BSID is skipped.

Thanks,
Ketan

On Sat, Feb 10, 2024 at 1:00 AM Yingzhen Qu  wrote:

> Hi,
>
> This email begins a 2 week WG adoption poll for the following 
> draft:draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress 
> Protection in Multi-homed scenario (ietf.org) 
> 
>
> Please review the document and indicate your support or objections by Feb 
> 24th, 2024.
>
> Please note that there is an existing WG 
> document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
> Protection 
>  
> Which proposes fast protections for the egress node and link of an SRv6 path 
> through extending IGP and using Mirror SID. As you discuss adopting 
> draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:
>
>
>- Do we need these different solutions?
>- Technical merits and drawbacks of each solution
>- If there is any implementation of the proposals, please voice it.
>
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to the draft.
>
> Also copying SPRING WG.
>
> Thanks,
> Yingzhen (RTGWG Co-chair)
>
> ___
> rtgwg mailing list
> rt...@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Huaimo Chen]

Hi Everyone,

Draft "SRv6 Egress Protection in Multi-homed scenario"
(draft-cheng-rtgwg-srv6-multihome-egress-protection)
provides SRv6 path egress protection for a specific scenario, where
the primary egress of the path and backup egress are dual-homed,
the service SID of the primary egress and the service SID of the backup
egress
have the same behavior and need to be distributed to the ingress of the
path.
Draft "SRv6 Path Egress Protection"
(draft-ietf-rtgwg-srv6-egress-protection)
provides SRv6 path egress protection for general cases,
including the specific scenario.

Best Regards,
Huaimo
On Wed, Feb 21, 2024 at 11:06 AM Ketan Talaulikar 
wrote:

> Hi Yingzhen/All,
>
> I have some concerns regarding the adoption of this document.
>
>
>- Do we need these different solutions?
>
> KT> No. There is one common author for both these drafts who is also from
> a vendor. I hope that person is also able to evaluate implementation
> aspects and pick one solution.
> KT> Does the adoption of this solution make the other draft "dead"?
>
>- Technical merits and drawbacks of each solution
>
> KT> The existing WG draft needs IGP protocol extensions and its
> implementation is very complex (as stated in the document under adoption).
>
>- If there is any implementation of the proposals, please voice it.
>
> KT> I think this is the key question and look forward to the answer.
>
> Coming to this document, please find below my comments/concerns:
>
> 1) There is no pseudocode for the new VPN behavior with PSD that covers
> the entire behavior - i.e., one that covers not just the "normal" case but
> the failure scenarios as well (e.g., PE/CE link failure).
> 2) The draft requires a transit IPv6 node to perform SRH processing for
> the SID that does not belong to it (this is some action that a P router
> needs to do when reachability to the PE is lost) and hence does not know
> what that SID behavior is. This is something very new for SRv6 and it can
> cause problems. e.g., consider the case that the active segment points to a
> BSID - what happens when a BSID is skipped.
>
> Thanks,
> Ketan
>
> On Sat, Feb 10, 2024 at 1:00 AM Yingzhen Qu 
> wrote:
>
>> Hi,
>>
>> This email begins a 2 week WG adoption poll for the following 
>> draft:draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress 
>> Protection in Multi-homed scenario (ietf.org) 
>> 
>>
>> Please review the document and indicate your support or objections by Feb 
>> 24th, 2024.
>>
>> Please note that there is an existing WG 
>> document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
>> Protection 
>>  
>> Which proposes fast protections for the egress node and link of an SRv6 path 
>> through extending IGP and using Mirror SID. As you discuss adopting 
>> draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:
>>
>>
>>- Do we need these different solutions?
>>- Technical merits and drawbacks of each solution
>>- If there is any implementation of the proposals, please voice it.
>>
>> Authors, please respond to the list indicating whether you are aware of any 
>> IPR that applies to the draft.
>>
>> Also copying SPRING WG.
>>
>> Thanks,
>> Yingzhen (RTGWG Co-chair)
>>
>> ___
>> rtgwg mailing list
>> rt...@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtgwg
>>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Huzhibo]

Hi Ketan/ALL:

Please see inline.
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Ketan Talaulikar
Sent: Thursday, February 22, 2024 12:06 AM
To: Yingzhen Qu 
Cc: RTGWG ; spring@ietf.org; rtgwg-chairs 
; draft-cheng-rtgwg-srv6-multihome-egress-protection 

Subject: Re: [spring] WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

Hi Yingzhen/All,

I have some concerns regarding the adoption of this document.


  *   Do we need these different solutions?
KT> No. There is one common author for both these drafts who is also from a 
vendor. I hope that person is also able to evaluate implementation aspects and 
pick one solution.
KT> Does the adoption of this solution make the other draft "dead"?
ZHiBO > I think these two solutions have different application scenarios. 
draft-ietf-rtgwg-srv6-egress-protection-16 is more cost-effective and suit for 
scenarios that require high encapsulation efficiency. 
draft-cheng-rtgwg-srv6-multihome-egress-protection-05
is more automated, and suit for scenarios that expected to reduce OPEX. I think 
the two solution can evolve in parallel.

  *   Technical merits and drawbacks of each solution
KT> The existing WG draft needs IGP protocol extensions and its implementation 
is very complex (as stated in the document under adoption).


  *   If there is any implementation of the proposals, please voice it.
KT> I think this is the key question and look forward to the answer.

Coming to this document, please find below my comments/concerns:


1)  There is no pseudocode for the new VPN behavior with PSD that covers the 
entire behavior - i.e., one that covers not just the "normal" case but the 
failure scenarios as well (e.g., PE/CE link failure).
ZHiBO > PSD only additionally extends the forwarding behavior with the VPN 
Sid at the penultimate hop. For details about how to switch to the next SRv6 
Sid in a fault scenario, see 
draft-chen-rtgwg-srv6-midpoint-protection-14<https://datatracker.ietf.org/doc/draft-chen-rtgwg-srv6-midpoint-protection/>.


2) The draft requires a transit IPv6 node to perform SRH processing for the SID 
that does not belong to it (this is some action that a P router needs to do 
when reachability to the PE is lost) and hence does not know what that SID 
behavior is. This is something very new for SRv6 and it can cause problems. 
e.g., consider the case that the active segment points to a BSID - what happens 
when a BSID is skipped.
   ZHiBO > Yes, this is the proxy forwarding behavior for the failure node. 
draft-li-rtgwg-enhanced-ti-lfa-09<https://datatracker.ietf.org/doc/draft-li-rtgwg-enhanced-ti-lfa/>
 describes how to prevent certain sids from being skipped.
Thanks,
Ketan

On Sat, Feb 10, 2024 at 1:00 AM Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:

Hi,



This email begins a 2 week WG adoption poll for the following draft:

draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress Protection 
in Multi-homed scenario 
(ietf.org)<https://datatracker.ietf.org/doc/draft-cheng-rtgwg-srv6-multihome-egress-protection/>



Please review the document and indicate your support or objections by Feb 24th, 
2024.

Please note that there is an existing WG 
document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
Protection<https://datatracker.ietf.org/doc/draft-ietf-rtgwg-srv6-egress-protection/>
 Which proposes fast protections for the egress node and link of an SRv6 path 
through extending IGP and using Mirror SID. As you discuss adopting 
draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:

· Do we need these different solutions?

· Technical merits and drawbacks of each solution

· If there is any implementation of the proposals, please voice it.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.

Also copying SPRING WG.

Thanks,

Yingzhen (RTGWG Co-chair)
___
rtgwg mailing list
rt...@ietf.org<mailto:rt...@ietf.org>
https://www.ietf.org/mailman/listinfo/rtgwg
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Libin Liu]

Hi Chair and WG,


I support the adoption of this draft.

I agree with that different solutions suit for different application scenarios. 
I think the authors can distinguish this more in the draft if necessary.


Best,

Libin



From: Yingzhen Qu [mailto:yingzhen.i...@gmail.com]
Sent: Saturday, February 10, 2024 3:30 AM
To: RTGWG; spring@ietf.org; rtgwg-chairs; 
draft-cheng-rtgwg-srv6-multihome-egress-protection
Subject: WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection 
(02/09/24 - 02/24/24)



Hi,



This email begins a 2 week WG adoption poll for the following draft:

draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress Protection 
in Multi-homed scenario 
(ietf.org)



Please review the document and indicate your support or objections by Feb 24th, 
2024.

Please note that there is an existing WG 
document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
Protection
 Which proposes fast protections for the egress node and link of an SRv6 path 
through extending IGP and using Mirror SID. As you discuss adopting 
draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:

* Do we need these different solutions?

* Technical merits and drawbacks of each solution

* If there is any implementation of the proposals, please voice it.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.

Also copying SPRING WG.

Thanks,

Yingzhen (RTGWG Co-chair)
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[wan...@centecnetworks.com]

Dear WG and the WG Chairs,

I support the adoption, from the perspective of a network chip vendor.

The solution mentioned in 
[draft-cheng-rtgwg-srv6-multihome-egress-protection-05] includes pre-arranging 
backup service SIDs.
When the tail node fails, it can easily realize the forwarding of the service 
SID of the next backup tail node.

The chip logic is simple, easy to implement, and has low overhead, without 
affecting forwarding performance. We implement this draft in Centec network 
chip products. 

Best regards



Junjie Wang
Suzhou Centec Communications Co., Ltd.
Web：www.centec.com
 
From: Yingzhen Qu
Date: 2024-02-10 03:30
To: RTGWG; spring; rtgwg-chairs; 
draft-cheng-rtgwg-srv6-multihome-egress-protection
Subject: [spring] WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)
Hi,
This email begins a 2 week WG adoption poll for the following draft:
draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress Protection 
in Multi-homed scenario (ietf.org)
Please review the document and indicate your support or objections by Feb 24th, 
2024.Please note that there is an existing WG 
document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
Protection Which proposes fast protections for the egress node and link of an 
SRv6 path through extending IGP and using Mirror SID. As you discuss adopting 
draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:
Do we need these different solutions?
Technical merits and drawbacks of each solution
If there is any implementation of the proposals, please voice it.
Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.Also copying SPRING WG.Thanks,
Yingzhen (RTGWG Co-chair)
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Gyan Mishra]

Dear WG

I reviewed both drafts which provides a completely different solution for
the same problem of optimization of egress protection of the L2 VPN EVPN or
L3 VPN SRv6 Service SID.

As both drafts provide completely different solutions for the same egress
PE VPN SID protection problem and may both yield different results as far
as link or node failover and recovery times based on vendor
implementations, they should both be progressed separately as their maybe
use cases where one solution maybe more applicable then the other solution
and vice versa.

WG adoption call draft

https://datatracker.ietf.org/doc/html/draft-cheng-rtgwg-srv6-multihome-egress-protection-05

This draft has IANA code point  allocation of a new SRv6 PGM RFC 8986 PSD
endpoint flavor for all L2 VPN EVPN and L3 VPN endpoints behaviors to
accommodate having an additional Backup VPN SID Segment List (o) position
in the SRH to backup the Primary VPN SiD in case of egress PE primary VPN
SID failure due to PE-CE attachment circuit failure and recovery using this
protected VPN SID solution.


Egress protection draft

https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-srv6-egress-protection-16

This draft provides a simplified egress protection mechanism by not
protecting the entire path via 1+1 backup candidate path, providing
protection of all SIDs along the path, alternatively an optimized solution
in this draft using a mirror SID to protect egress PE L2 VPN EVPN or L3 VPN
SRv6 Service SID.



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*



On Fri, Feb 9, 2024 at 2:30 PM Yingzhen Qu  wrote:

> Hi,
>
> This email begins a 2 week WG adoption poll for the following 
> draft:draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress 
> Protection in Multi-homed scenario (ietf.org) 
> 
>
> Please review the document and indicate your support or objections by Feb 
> 24th, 2024.
>
> Please note that there is an existing WG 
> document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
> Protection 
>  
> Which proposes fast protections for the egress node and link of an SRv6 path 
> through extending IGP and using Mirror SID. As you discuss adopting 
> draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:
>
>
>- Do we need these different solutions?
>- Technical merits and drawbacks of each solution
>- If there is any implementation of the proposals, please voice it.
>
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to the draft.
>
> Also copying SPRING WG.
>
> Thanks,
> Yingzhen (RTGWG Co-chair)
>
> ___
> rtgwg mailing list
> rt...@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Lancheng Qin]

Dear WG,

I reviewed both drafts and support the adoption of this draft, because I think 
the new solution would help improve the robustness in the case of egress node 
failure.

Best,

Lancheng



-原始邮件-
发件人:"Yingzhen Qu" 
发送时间:2024-02-10 03:30:18 (星期六)
收件人: RTGWG , spring@ietf.org, rtgwg-chairs 
, draft-cheng-rtgwg-srv6-multihome-egress-protection 

主题: WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection 
(02/09/24 - 02/24/24)


Hi,

This email begins a 2 week WG adoption poll for the following draft: 
draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress Protection 
in Multi-homed scenario (ietf.org) Please review the document and indicate your 
support or objections by Feb 24th, 2024.
Please note that there is an existing WG 
document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
Protection Which proposes fast protections for the egress node and link of an 
SRv6 path through extending IGP and using Mirror SID. As you discuss adopting 
draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:
Do we need these different solutions?
Technical merits and drawbacks of each solution
If there is any implementation of the proposals, please voice it.
Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.
Also copying SPRING WG.
Thanks,
Yingzhen (RTGWG Co-chair)___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Weiqiang Cheng]

Hi All,
As a co-author, I support the WG adoption.

Regarding questions 1 and 2: Yes, the both drafts are necessary. These two 
proposals represent two completely different solutions for different 
application scenarios. Draft-cheng-rtgwg-srv6-multihome-egress-protection-05 
provides a data plane method in line with the SR design principle, suitable for 
scenarios where routers have the flexibility in data plane programming; 
draft-ietf-rtgwg-srv6-egress-protection-16 offers a control plane extension 
solution, suitable for scenarios where control plane software upgrades are 
convenient. 
Regarding question 3: Multiple device manufacturers and chip vendors have 
implemented the technical solution described in 
draft-cheng-rtgwg-srv6-multihome-egress-protection-05, and China Mobile has 
conducted lab tests, with results meeting expectations.

I am not aware of any undisclosed IPR.

Best Regards,
Weiqiang Cheng
 
From: Yingzhen Qu
Date: 2024-02-10 03:30
To: RTGWG; spring; rtgwg-chairs; 
draft-cheng-rtgwg-srv6-multihome-egress-protection
Subject: WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection 
(02/09/24 - 02/24/24)
Hi,
This email begins a 2 week WG adoption poll for the following draft:
draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress Protection 
in Multi-homed scenario (ietf.org)
Please review the document and indicate your support or objections by Feb 24th, 
2024.Please note that there is an existing WG 
document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
Protection Which proposes fast protections for the egress node and link of an 
SRv6 path through extending IGP and using Mirror SID. As you discuss adopting 
draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:
Do we need these different solutions?
Technical merits and drawbacks of each solution
If there is any implementation of the proposals, please voice it.
Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.Also copying SPRING WG.Thanks,
Yingzhen (RTGWG Co-chair)
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call-draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Wenying Jiang]

Hi All，

As a co-author, I support the WG adoption.

 

I am not aware of any undisclosed IPR related to this document.

 

BR.

Wenying





邮件原文发件人：Yingzhen Qu  收件人：RTGWG  
,spring ,rtgwg-chairs  
,draft-cheng-rtgwg-srv6-multihome-egress-protection 
抄　送: 
(无)发送时间：2024-02-10 03:30:18主题：[spring] WG Adoption Call 
-draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)Hi,

This email begins a 2 week WG adoption poll for the following 
draft:draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress 
Protection in Multi-homed scenario (ietf.org)Please review the document and 
indicate your support or objections by Feb 24th, 2024.Please note that there is 
an existing WG document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path 
Egress Protection Which proposes fast protections for the egress node and link 
of an SRv6 path through extending IGP and using Mirror SID. As you discuss 
adopting draft-cheng-rtgwg-srv6-multihome-egress-protection, please also 
consider:Do we need these different solutions?

Technical merits and drawbacks of each solution

If there is any implementation of the proposals, please voice it.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.Also copying SPRING WG.Thanks,
Yingzhen (RTGWG Co-chair)







___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call -draft-cheng-rtgwg-srv6-multihome-egress-protection(02/09/24 - 02/24/24)

[Wenying Jiang]

Hi All，


As a co-author, I support the WG adoption.


 


I am not aware of any undisclosed IPR related to this document.


 


BR.


Wenying












邮件原文发件人：Yingzhen Qu  收件人：RTGWG  
,spring ,rtgwg-chairs  
,draft-cheng-rtgwg-srv6-multihome-egress-protection  
抄　送: 
(无)发送时间：2024-02-10 03:30:18主题：WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection(02/09/24 - 02/24/24)Hi,

This email begins a 2 week WG adoption poll for the following 
draft:draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress 
Protection in Multi-homed scenario (ietf.org)Please review the document and 
indicate your support or objections by Feb 24th, 2024.Please note that there is 
an existing WG document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path 
Egress Protection Which proposes fast protections for the egress node and link 
of an SRv6 path through extending IGP and using Mirror SID. As you discuss 
adopting draft-cheng-rtgwg-srv6-multihome-egress-protection, please also 
consider:Do we need these different solutions?

Technical merits and drawbacks of each solution

If there is any implementation of the proposals, please voice it.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.Also copying SPRING WG.Thanks,
Yingzhen (RTGWG Co-chair)







___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection(02/09/24 - 02/24/24)

[Wenying Jiang]

Hi All，


As a co-author, I support the WG adoption.


 


I am not aware of any undisclosed IPR related to this document.


 


BR.


Wenying










邮件原文发件人：Yingzhen Qu  收件人：RTGWG  
,spring ,rtgwg-chairs  
,draft-cheng-rtgwg-srv6-multihome-egress-protection  
抄　送: 
(无)发送时间：2024-02-10 03:30:18主题：WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection(02/09/24 - 02/24/24)Hi,

This email begins a 2 week WG adoption poll for the following 
draft:draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress 
Protection in Multi-homed scenario (ietf.org)Please review the document and 
indicate your support or objections by Feb 24th, 2024.Please note that there is 
an existing WG document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path 
Egress Protection Which proposes fast protections for the egress node and link 
of an SRv6 path through extending IGP and using Mirror SID. As you discuss 
adopting draft-cheng-rtgwg-srv6-multihome-egress-protection, please also 
consider:Do we need these different solutions?

Technical merits and drawbacks of each solution

If there is any implementation of the proposals, please voice it.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.Also copying SPRING WG.Thanks,
Yingzhen (RTGWG Co-chair)







___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Yingzhen Qu]

Dear SPRING WG and chairs,

I'd like to bring your attention to this adoption call happening in the
RTGWG WG.

The draft describes a SRv6 egress node protection mechanism in multi-home
scenarios. As Ketan has commented in his email below the proposal requires
a P router to process SRH with new endpoint behavior.

We'd like to get your comments about the proposed extensions. Please send
your reply to both the SPRING and RTGWG mailing lists.

Thanks,
Yingzhen

On Wed, Feb 21, 2024 at 8:06 AM Ketan Talaulikar 
wrote:

> Hi Yingzhen/All,
>
> I have some concerns regarding the adoption of this document.
>
>
>- Do we need these different solutions?
>
> KT> No. There is one common author for both these drafts who is also from
> a vendor. I hope that person is also able to evaluate implementation
> aspects and pick one solution.
> KT> Does the adoption of this solution make the other draft "dead"?
>
>- Technical merits and drawbacks of each solution
>
> KT> The existing WG draft needs IGP protocol extensions and its
> implementation is very complex (as stated in the document under adoption).
>
>- If there is any implementation of the proposals, please voice it.
>
> KT> I think this is the key question and look forward to the answer.
>
> Coming to this document, please find below my comments/concerns:
>
> 1) There is no pseudocode for the new VPN behavior with PSD that covers
> the entire behavior - i.e., one that covers not just the "normal" case but
> the failure scenarios as well (e.g., PE/CE link failure).
> 2) The draft requires a transit IPv6 node to perform SRH processing for
> the SID that does not belong to it (this is some action that a P router
> needs to do when reachability to the PE is lost) and hence does not know
> what that SID behavior is. This is something very new for SRv6 and it can
> cause problems. e.g., consider the case that the active segment points to a
> BSID - what happens when a BSID is skipped.
>
> Thanks,
> Ketan
>
> On Sat, Feb 10, 2024 at 1:00 AM Yingzhen Qu 
> wrote:
>
>> Hi,
>>
>> This email begins a 2 week WG adoption poll for the following 
>> draft:draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress 
>> Protection in Multi-homed scenario (ietf.org) 
>> 
>>
>> Please review the document and indicate your support or objections by Feb 
>> 24th, 2024.
>>
>> Please note that there is an existing WG 
>> document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress 
>> Protection 
>>  
>> Which proposes fast protections for the egress node and link of an SRv6 path 
>> through extending IGP and using Mirror SID. As you discuss adopting 
>> draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:
>>
>>
>>- Do we need these different solutions?
>>- Technical merits and drawbacks of each solution
>>- If there is any implementation of the proposals, please voice it.
>>
>> Authors, please respond to the list indicating whether you are aware of any 
>> IPR that applies to the draft.
>>
>> Also copying SPRING WG.
>>
>> Thanks,
>> Yingzhen (RTGWG Co-chair)
>>
>> ___
>> rtgwg mailing list
>> rt...@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtgwg
>>
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[bruno . decraene]

Dear Yingzhen,

At your request, I have quickly parsed the draft.

It's not completely clear to me how the solution works given that the 
terminology used is a bit loose.

2 questions on the terminology:

1) "protection" vs "restoration". The document largely uses the term 
"protection", in particular in its title. This usually assumes that protection 
is precomputed, local to the penultimate node (before the failure) and hence 
can be fast.
I'm assuming that "protection" is indeed meant. Please correct me if this is 
wrong. In which case, the node doing the protection is usually called PLR and 
is reacting before the IGP convergence. If so, it would be good for the 
document to reflect this (use the term PLR, remove the reference to IGP fast 
convergence)
(On the other hand, if would meant restoration following IGP convergence, the 
gain seems limited to me as the ingress would equally be able to react to IGP 
convergence and with PIC edge it would do it fast)

2) "Penultinate node" vs "penultimate Endpoint."
RFC 8754 defines different type of nodes. 
https://datatracker.ietf.org/doc/html/rfc8754#section-3
In particular, a transit node is a regular IPv6 router which does not process 
the SRH. While a EndPoint is a node receiving an IPv6 packet where the 
destination address of that packet is locally configured as a segment or local 
interface

Can you please clarify whether your Penultimate Endpoint (§3.3) is a Transit 
Node or an SR Segment Endpoint Node?

- If the Penultimate Endpoint (§3.3) is a Transit Node, then as per RFC8200 
it's not allowed to process the SRH. 
https://datatracker.ietf.org/doc/html/rfc8200#section-4 Hence your proposal 
would not be compliant with RFC 8200
- If the Penultimate Endpoint (§3.3) is an SR Segment Endpoint Node, the 
Ingress needs to specifically adds a Segment of this node. (typically End or 
End.X). If so please clarify this in the document (in particular in§3.1). Note 
that by doing so, you are adding a new point of failure (the failure of this 
Penultimate Endpoint). How do you protect from this added case of failure? If 
you don't, I would argue that the gain is debatable as you replace one type of 
failure (PE failure) by another type of failure (P failure).


I have another question on §3.3
How does the penultimate Endpoint know that it can/needs to perform the new 
behavior? My guess would be by looking at the next SID (the one from the 
egress) and discovering that the behavior of this SID is End.D* with PSD. That 
would seem to require this P node to be aware of all VPN routes, which is 
typically not the case, frown upon and does not scale well as the P nodes would 
have 10s of PE (if not 100).

On a side note, the abstract seems a bit short to me.

So thanks for clarifying the document,
Regards,
--Bruno

> 
> -Original Message-
> From: Yingzhen Qu 
> Sent: Sunday, February 25, 2024 6:44 AM
> To: Ketan Talaulikar ; spring-cha...@ietf.org
> Cc: RTGWG ; spring@ietf.org; rtgwg-chairs 
> ; draft-cheng-rtgwg-srv6-multihome-egress-protection 
> 
> Subject: Re: WG Adoption Call - 
> draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)
> 
> Dear SPRING WG and chairs,
> 
> I'd like to bring your attention to this adoption call happening in the RTGWG 
> WG.
> 
> The draft describes a SRv6 egress node protection mechanism in multi-home 
> scenarios. As Ketan has commented in his email below the proposal requires a 
> P router to process SRH with new endpoint behavior.
> 
> We'd like to get your comments about the proposed extensions. Please send 
> your reply to both the SPRING and RTGWG mailing lists.
> 
> Thanks,
> Yingzhen
> 
> On Wed, Feb 21, 2024 at 8:06 AM Ketan Talaulikar 
> wrote:
> 
> > Hi Yingzhen/All,
> >
> > I have some concerns regarding the adoption of this document.
> >
> >
> >- Do we need these different solutions?
> >
> > KT> No. There is one common author for both these drafts who is also
> > KT> from
> > a vendor. I hope that person is also able to evaluate implementation
> > aspects and pick one solution.
> > KT> Does the adoption of this solution make the other draft "dead"?
> >
> >- Technical merits and drawbacks of each solution
> >
> > KT> The existing WG draft needs IGP protocol extensions and its
> > implementation is very complex (as stated in the document under
> > adoption)
>

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
inf

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Yingzhen Qu]

Hi Bruno,

Thank you for the feedback, really appreciate it.

Let me try to answer your questions with my understanding, and the authors
please chime in.

Thanks,
Yingzhen

On Mon, Feb 26, 2024 at 5:07 AM  wrote:

> Dear Yingzhen,
>
> At your request, I have quickly parsed the draft.
>
> It's not completely clear to me how the solution works given that the
> terminology used is a bit loose.
>
> 2 questions on the terminology:
>
> 1) "protection" vs "restoration". The document largely uses the term
> "protection", in particular in its title. This usually assumes that
> protection is precomputed, local to the penultimate node (before the
> failure) and hence can be fast.
> I'm assuming that "protection" is indeed meant. Please correct me if this
> is wrong. In which case, the node doing the protection is usually called
> PLR and is reacting before the IGP convergence. If so, it would be good for
> the document to reflect this (use the term PLR, remove the reference to IGP
> fast convergence)
> (On the other hand, if would meant restoration following IGP convergence,
> the gain seems limited to me as the ingress would equally be able to react
> to IGP convergence and with PIC edge it would do it fast)
>
> [Yingzhen]:  "Protection" is the right term.

2) "Penultinate node" vs "penultimate Endpoint."
> RFC 8754 defines different type of nodes.
> https://datatracker.ietf.org/doc/html/rfc8754#section-3
> In particular, a transit node is a regular IPv6 router which does not
> process the SRH. While a EndPoint is a node receiving an IPv6 packet where
> the destination address of that packet is locally configured as a segment
> or local interface
>
> Can you please clarify whether your Penultimate Endpoint (§3.3) is a
> Transit Node or an SR Segment Endpoint Node?


> - If the Penultimate Endpoint (§3.3) is a Transit Node, then as per
> RFC8200 it's not allowed to process the SRH.
> https://datatracker.ietf.org/doc/html/rfc8200#section-4 Hence your
> proposal would not be compliant with RFC 8200
> - If the Penultimate Endpoint (§3.3) is an SR Segment Endpoint Node, the
> Ingress needs to specifically adds a Segment of this node. (typically End
> or End.X). If so please clarify this in the document (in particular
> in§3.1). Note that by doing so, you are adding a new point of failure (the
> failure of this Penultimate Endpoint). How do you protect from this added
> case of failure? If you don't, I would argue that the gain is debatable as
> you replace one type of failure (PE failure) by another type of failure (P
> failure).
>
> [Yingzhen]: This should be "penultimate SR segment endpoint". A transit
node may not have the capability to process a SRH. With that being said,
the penultimate SR endpoint may be several hops away from the PE, and this
requires some failure detection mechanisms, such as multi-hop BFD.

>
> I have another question on §3.3
> How does the penultimate Endpoint know that it can/needs to perform the
> new behavior? My guess would be by looking at the next SID (the one from
> the egress) and discovering that the behavior of this SID is End.D* with
> PSD. That would seem to require this P node to be aware of all VPN routes,
> which is typically not the case, frown upon and does not scale well as the
> P nodes would have 10s of PE (if not 100).
>
> [Yingzhen]: my understanding is that this protection mechanism is not to
be deployed for all PEs, but only a subset of them. Otherwise I agree with
you that it doesn't scale.

On a side note, the abstract seems a bit short to me.
>
> So thanks for clarifying the document,
> Regards,
> --Bruno
>
> >
> > -Original Message-
> > From: Yingzhen Qu 
> > Sent: Sunday, February 25, 2024 6:44 AM
> > To: Ketan Talaulikar ; spring-cha...@ietf.org
> > Cc: RTGWG ; spring@ietf.org; rtgwg-chairs <
> rtgwg-cha...@ietf.org>;
> draft-cheng-rtgwg-srv6-multihome-egress-protection <
> draft-cheng-rtgwg-srv6-multihome-egress-protect...@ietf.org>
> > Subject: Re: WG Adoption Call -
> draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)
> >
> > Dear SPRING WG and chairs,
> >
> > I'd like to bring your attention to this adoption call happening in the
> RTGWG WG.
> >
> > The draft describes a SRv6 egress node protection mechanism in
> multi-home scenarios. As Ketan has commented in his email below the
> proposal requires a P router to process SRH with new endpoint behavior.
> >
> > We'd like to get your comments about the proposed extensions. Please
> send your reply to both the SPRING and RTGWG mailing lists.
> >
> > Thanks,
> > Yingzhen
> >
> > On Wed, Feb 21, 2024 at 8:06 AM Ketan Talaulikar 
> > wrote:
> >
> > > Hi Yingzhen/All,
> > >
> > > I have some concerns regarding the adoption of this document.
> > >
> > >
> > >- Do we need these different solutions?
> > >
> > > KT> No. There is one common author for both these drafts who is also
> > > KT> from
> > > a vendor. I hope that person is also able to evaluate implementation
> > > aspects and pi

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[bruno . decraene]

Hi Yingzhen,

Thank you for your answers and clarification. That really helps.
Please see inline [Bruno]

From: Yingzhen Qu 
Sent: Tuesday, February 27, 2024 3:42 AM
To: DECRAENE Bruno INNOV/NET 
Cc: Ketan Talaulikar ; RTGWG ; 
draft-cheng-rtgwg-srv6-multihome-egress-protection 
; rtgwg-chairs 
; spring-cha...@ietf.org; spring@ietf.org
Subject: Re: WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

Hi Bruno,

Thank you for the feedback, really appreciate it.

Let me try to answer your questions with my understanding, and the authors 
please chime in.

Thanks,
Yingzhen

On Mon, Feb 26, 2024 at 5:07 AM 
mailto:bruno.decra...@orange.com>> wrote:
Dear Yingzhen,

At your request, I have quickly parsed the draft.

It's not completely clear to me how the solution works given that the 
terminology used is a bit loose.

2 questions on the terminology:

1) "protection" vs "restoration". The document largely uses the term 
"protection", in particular in its title. This usually assumes that protection 
is precomputed, local to the penultimate node (before the failure) and hence 
can be fast.
I'm assuming that "protection" is indeed meant. Please correct me if this is 
wrong. In which case, the node doing the protection is usually called PLR and 
is reacting before the IGP convergence. If so, it would be good for the 
document to reflect this (use the term PLR, remove the reference to IGP fast 
convergence)
(On the other hand, if would meant restoration following IGP convergence, the 
gain seems limited to me as the ingress would equally be able to react to IGP 
convergence and with PIC edge it would do it fast)
[Yingzhen]:  "Protection" is the right term.

[Bruno] OK. Therefore that’s before the IGP convergence. Could you please 
remove the references to IGP convergences?

2) "Penultinate node" vs "penultimate Endpoint."
RFC 8754 defines different type of nodes. 
https://datatracker.ietf.org/doc/html/rfc8754#section-3
In particular, a transit node is a regular IPv6 router which does not process 
the SRH. While a EndPoint is a node receiving an IPv6 packet where the 
destination address of that packet is locally configured as a segment or local 
interface

Can you please clarify whether your Penultimate Endpoint (§3.3) is a Transit 
Node or an SR Segment Endpoint Node?

- If the Penultimate Endpoint (§3.3) is a Transit Node, then as per RFC8200 
it's not allowed to process the SRH. 
https://datatracker.ietf.org/doc/html/rfc8200#section-4 Hence your proposal 
would not be compliant with RFC 8200
- If the Penultimate Endpoint (§3.3) is an SR Segment Endpoint Node, the 
Ingress needs to specifically adds a Segment of this node. (typically End or 
End.X). If so please clarify this in the document (in particular in§3.1). Note 
that by doing so, you are adding a new point of failure (the failure of this 
Penultimate Endpoint). How do you protect from this added case of failure? If 
you don't, I would argue that the gain is debatable as you replace one type of 
failure (PE failure) by another type of failure (P failure).
[Yingzhen]: This should be "penultimate SR segment endpoint". A transit node 
may not have the capability to process a SRH. With that being said, the 
penultimate SR endpoint may be several hops away from the PE, and this requires 
some failure detection mechanisms, such as multi-hop BFD.

[Bruno] OK. Could you please clarify this in the draft? (the name and the need 
for multi-hop BFD hence a discussion about scaling and probably configuration.)
Do we agree that in the absence of an SR-Policy, that penultimate SR segment 
endpoint is in fact the ingress PE hence nothing changed? If so, could you 
please clarify in the draft that this only applies to traffic using SR-policies?


I have another question on §3.3
How does the penultimate Endpoint know that it can/needs to perform the new 
behavior? My guess would be by looking at the next SID (the one from the 
egress) and discovering that the behavior of this SID is End.D* with PSD. That 
would seem to require this P node to be aware of all VPN routes, which is 
typically not the case, frown upon and does not scale well as the P nodes would 
have 10s of PE (if not 100).
[Yingzhen]: my understanding is that this protection mechanism is not to be 
deployed for all PEs, but only a subset of them. Otherwise I agree with you 
that it doesn't scale.

[Bruno] OK. Could you please clarify in the draft that this solution requires, 
on the penultimate SR segment endpoint, i.e., a P node, the knowledge of all 
VPN routes of the nominal PE which need to be protected by backup PE (and in 
the absence of configuration, this likely requires this P to have the 
knowledge, in the control plane, of all VPN routes).
Plus given that the dataplane needs to check the next SID in the SRH, it also 
requires the knowledge of the protected routes in the dataplane/FIB. If so, 
it’s not clear to me what’s the benefit of adding the backup SID in t

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Weiqiang Cheng]

Hi Bruno and Yingzhen,
Thank you very much for your insightful comments and guidance.
Please see co-authors' feedback inline [co-author]. 

Thanks,
Weiqiang Cheng


 
From: bruno.decraene
Date: 2024-02-27 16:12
To: Yingzhen Qu
CC: Ketan Talaulikar; RTGWG; 
draft-cheng-rtgwg-srv6-multihome-egress-protection; rtgwg-chairs; 
spring-cha...@ietf.org; spring@ietf.org
Subject: Re: [spring] WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)
Hi Yingzhen,
 
Thank you for your answers and clarification. That really helps.
Please see inline [Bruno]
 
From: Yingzhen Qu  
Sent: Tuesday, February 27, 2024 3:42 AM
To: DECRAENE Bruno INNOV/NET 
Cc: Ketan Talaulikar ; RTGWG ; 
draft-cheng-rtgwg-srv6-multihome-egress-protection 
; rtgwg-chairs 
; spring-cha...@ietf.org; spring@ietf.org
Subject: Re: WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)
 
Hi Bruno,
 
Thank you for the feedback, really appreciate it.
 
Let me try to answer your questions with my understanding, and the authors 
please chime in.
 
Thanks,
Yingzhen
 
On Mon, Feb 26, 2024 at 5:07 AM  wrote:
Dear Yingzhen,

At your request, I have quickly parsed the draft.

It's not completely clear to me how the solution works given that the 
terminology used is a bit loose.

2 questions on the terminology:

1) "protection" vs "restoration". The document largely uses the term 
"protection", in particular in its title. This usually assumes that protection 
is precomputed, local to the penultimate node (before the failure) and hence 
can be fast.
I'm assuming that "protection" is indeed meant. Please correct me if this is 
wrong. In which case, the node doing the protection is usually called PLR and 
is reacting before the IGP convergence. If so, it would be good for the 
document to reflect this (use the term PLR, remove the reference to IGP fast 
convergence)
(On the other hand, if would meant restoration following IGP convergence, the 
gain seems limited to me as the ingress would equally be able to react to IGP 
convergence and with PIC edge it would do it fast)
[Yingzhen]:  "Protection" is the right term. 
 
[Bruno] OK. Therefore that’s before the IGP convergence. Could you please 
remove the references to IGP convergences?

[co-authors]  OK. We will be updated in the new version.

2) "Penultinate node" vs "penultimate Endpoint."
RFC 8754 defines different type of nodes. 
https://datatracker.ietf.org/doc/html/rfc8754#section-3
In particular, a transit node is a regular IPv6 router which does not process 
the SRH. While a EndPoint is a node receiving an IPv6 packet where the 
destination address of that packet is locally configured as a segment or local 
interface

Can you please clarify whether your Penultimate Endpoint (§3.3) is a Transit 
Node or an SR Segment Endpoint Node?

- If the Penultimate Endpoint (§3.3) is a Transit Node, then as per RFC8200 
it's not allowed to process the SRH. 
https://datatracker.ietf.org/doc/html/rfc8200#section-4 Hence your proposal 
would not be compliant with RFC 8200
- If the Penultimate Endpoint (§3.3) is an SR Segment Endpoint Node, the 
Ingress needs to specifically adds a Segment of this node. (typically End or 
End.X). If so please clarify this in the document (in particular in§3.1). Note 
that by doing so, you are adding a new point of failure (the failure of this 
Penultimate Endpoint). How do you protect from this added case of failure? If 
you don't, I would argue that the gain is debatable as you replace one type of 
failure (PE failure) by another type of failure (P failure).
[Yingzhen]: This should be "penultimate SR segment endpoint". A transit node 
may not have the capability to process a SRH. With that being said, the 
penultimate SR endpoint may be several hops away from the PE, and this requires 
some failure detection mechanisms, such as multi-hop BFD.  
 
[Bruno] OK. Could you please clarify this in the draft? (the name and the need 
for multi-hop BFD hence a discussion about scaling and probably configuration.)
Do we agree that in the absence of an SR-Policy, that penultimate SR segment 
endpoint is in fact the ingress PE hence nothing changed? If so, could you 
please clarify in the draft that this only applies to traffic using SR-policies?

[co-authors]  This draft is not limited to the SR-Policy scenario. If there is 
no SR-Policy configured and only two SIDs exist, namely primary and backup, any 
intermediate node can bypass the failed tail node.
This can be enabled using a command control to activate this feature, or by 
extending a flag in the SRH header to indicate that skipping can be performed.
We will update the description in the next version.
 

I have another question on §3.3
How does the penultimate Endpoint know that it can/needs to perform the new 
behavior? My guess would be by looking at the next SID (the

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Alvaro Retana]

Hi!

Now that the terminology is a little more precise, I also looked at the
document and found a couple of cases where SIDs are skipped by SRv6 segment
endpoints, which is what Ketan is really concerned about (?).

These cases (see below) do not align with rfc8754 or rfc8986.  IMO, any
proposed deviation from the existing specifications should be discussed in
spring (for rfc8986) or 6man (for rfc8754), and formal Updates to those
RFCs may be needed.

Thanks!

Alvaro.


(1) From §3.3 (Procedure on the Penultimate Endpoint):

   IF the primary outbound interface used to forward the packet failed
   or there is no FIB entry for forwarding the packet, the detailed
   processing to be performed by the penultimate node is as follows:

 IF SL = 1 THEN
SL decreases by 1 and becomes 0;
Update the IPv6 DA with Segment List[0];
FIB lookup on the updated DA;
Forward the packet according to the matched entry;


There seem to be two cases here: "the primary outbound interface used to
forward the packet failed" and "there is no FIB entry for forwarding the
packet".  I assume (?) they are grouped because the result is that there is
no FIB entry for the destination -- IOW, the link going down results in no
alternate path available.

rfc8754 covers this case:

   4.3.4. FIB Entry Is a No Match

  Processing is not changed by this document.


The result of a non-existent FIB entry is to drop the packet, not to
forward it, as mentioned above.  Changing that action requires an Update to
rfc8754 (and others).

As Bruno pointed out, questions related to "how does the node know" come up.



(2) The operation described in this draft depends on P2 (Figure 3) taking
on the role of the "Penultimate Endpoint".  But the SRH used to illustrate
is "< A1:1::1, A2:1::A100, A3:1::B100, A4:1::B100>", which results in P2
being in the Segment List[2] position.

Also, PE3 also has penultimate endpoint functions in the draft.

rfc8754 and rfc8986 have explicit definitions of what the penultimate
segment endpoint is, and the use of P2 doesn't match any of them:

rfc8754:

   Segment List[0..n]: 128-bit IPv6 addresses representing the nth
  segment in the Segment List. The Segment List is encoded starting
  from the last segment of the SR Policy. That is, the first element
  of the Segment List (Segment List[0]) contains the last segment of
  the SR Policy, the second element contains the penultimate segment
  of the SR Policy, and so on.


rfc8986:

   A PSP-flavored SID is used by the SR source node when it needs to
   instruct the penultimate SR Segment Endpoint Node listed in the SRH
   to remove the SRH from the IPv6 header.
   ...
   A penultimate SR Segment Endpoint Node is one that, as part of the
   SID processing, copies the last SID from the SRH into the IPv6
   Destination Address and decrements the Segments Left value from one
   to zero.

   The PSP operation only takes place at a penultimate SR Segment
   Endpoint Node and does not happen at any transit node. When a SID of
   PSP flavor is processed at a non-penultimate SR Segment Endpoint
   Node, the PSP behavior is not performed as described in the
   pseudocode below since Segments Left would not be zero.


There are both terminology (using "penultimate" to describe any node other
than the one at Segment List[1]) and operation changes that would be
required in rfc8754 and rfc8986.



(3) From §4:

   In normal operations...The specific operations of PE3 are as follows:

   1) Remove the outer packet header and all its extension headers.

   2) Look up the FIB table according to the destination address of the
  original packet.

   3) Send the packet to CE2 according to the FIB entry.


First, much more is needed to explain the operation (codifying with
pseudocode as all the other SRH-related operations).  The PSP flavor is
specified in §4.16.1.2/rfc8986; it includes "S14. Update IPv6 DA with
Segment List[Segments Left]" (not the "destination address of the original
packet", as indicated above).

Changing how the PSP flavor works in "normal operations" would require an
Update of rfc8986.  Note that this draft doesn't indicate how P2 would know
the proposed process would have to be used (vs existing cases).

On February 25, 2024 at 12:44:18 AM, Yingzhen Qu (yingzhen.i...@gmail.com)
wrote:

Dear SPRING WG and chairs,

I'd like to bring your attention to this adoption call happening in the
RTGWG WG.

The draft describes a SRv6 egress node protection mechanism in multi-home
scenarios. As Ketan has commented in his email below the proposal requires
a P router to process SRH with new endpoint behavior.

We'd like to get your comments about the proposed extensions. Please send
your reply to both the SPRING and RTGWG mailing lists.

Thanks,
Yingzhen

On Wed, Feb 21, 2024 at 8:06 AM Ketan Talaulikar 
wrote:

> Hi Yingzhen/All,
>
> I have some concerns regarding the adoption of this document.
>
>
> - Do we

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Ketan Talaulikar]

Hi Alvaro,

You've got my concern! And you have also brought out all the details that
need to be clarified and worked through for this proposal.

Thanks,
Ketan


On Wed, Feb 28, 2024 at 6:24 PM Alvaro Retana 
wrote:

>
> Hi!
>
> Now that the terminology is a little more precise, I also looked at the
> document and found a couple of cases where SIDs are skipped by SRv6 segment
> endpoints, which is what Ketan is really concerned about (?).
>
> These cases (see below) do not align with rfc8754 or rfc8986.  IMO, any
> proposed deviation from the existing specifications should be discussed in
> spring (for rfc8986) or 6man (for rfc8754), and formal Updates to those
> RFCs may be needed.
>
> Thanks!
>
> Alvaro.
>
>
> (1) From §3.3 (Procedure on the Penultimate Endpoint):
>
>IF the primary outbound interface used to forward the packet failed
>or there is no FIB entry for forwarding the packet, the detailed
>processing to be performed by the penultimate node is as follows:
>
>  IF SL = 1 THEN
> SL decreases by 1 and becomes 0;
> Update the IPv6 DA with Segment List[0];
> FIB lookup on the updated DA;
> Forward the packet according to the matched entry;
>
>
> There seem to be two cases here: "the primary outbound interface used to
> forward the packet failed" and "there is no FIB entry for forwarding the
> packet".  I assume (?) they are grouped because the result is that there is
> no FIB entry for the destination -- IOW, the link going down results in no
> alternate path available.
>
> rfc8754 covers this case:
>
>4.3.4. FIB Entry Is a No Match
>
>   Processing is not changed by this document.
>
>
> The result of a non-existent FIB entry is to drop the packet, not to
> forward it, as mentioned above.  Changing that action requires an Update to
> rfc8754 (and others).
>
> As Bruno pointed out, questions related to "how does the node know" come
> up.
>
>
>
> (2) The operation described in this draft depends on P2 (Figure 3) taking
> on the role of the "Penultimate Endpoint".  But the SRH used to illustrate
> is "< A1:1::1, A2:1::A100, A3:1::B100, A4:1::B100>", which results in P2
> being in the Segment List[2] position.
>
> Also, PE3 also has penultimate endpoint functions in the draft.
>
> rfc8754 and rfc8986 have explicit definitions of what the penultimate
> segment endpoint is, and the use of P2 doesn't match any of them:
>
> rfc8754:
>
>Segment List[0..n]: 128-bit IPv6 addresses representing the nth
>   segment in the Segment List. The Segment List is encoded starting
>   from the last segment of the SR Policy. That is, the first element
>   of the Segment List (Segment List[0]) contains the last segment of
>   the SR Policy, the second element contains the penultimate segment
>   of the SR Policy, and so on.
>
>
> rfc8986:
>
>A PSP-flavored SID is used by the SR source node when it needs to
>instruct the penultimate SR Segment Endpoint Node listed in the SRH
>to remove the SRH from the IPv6 header.
>...
>A penultimate SR Segment Endpoint Node is one that, as part of the
>SID processing, copies the last SID from the SRH into the IPv6
>Destination Address and decrements the Segments Left value from one
>to zero.
>
>The PSP operation only takes place at a penultimate SR Segment
>Endpoint Node and does not happen at any transit node. When a SID of
>PSP flavor is processed at a non-penultimate SR Segment Endpoint
>Node, the PSP behavior is not performed as described in the
>pseudocode below since Segments Left would not be zero.
>
>
> There are both terminology (using "penultimate" to describe any node other
> than the one at Segment List[1]) and operation changes that would be
> required in rfc8754 and rfc8986.
>
>
>
> (3) From §4:
>
>In normal operations...The specific operations of PE3 are as follows:
>
>1) Remove the outer packet header and all its extension headers.
>
>2) Look up the FIB table according to the destination address of the
>   original packet.
>
>3) Send the packet to CE2 according to the FIB entry.
>
>
> First, much more is needed to explain the operation (codifying with
> pseudocode as all the other SRH-related operations).  The PSP flavor is
> specified in §4.16.1.2/rfc8986; it includes "S14. Update IPv6 DA with
> Segment List[Segments Left]" (not the "destination address of the original
> packet", as indicated above).
>
> Changing how the PSP flavor works in "normal operations" would require an
> Update of rfc8986.  Note that this draft doesn't indicate how P2 would know
> the proposed process would have to be used (vs existing cases).
>
> On February 25, 2024 at 12:44:18 AM, Yingzhen Qu (yingzhen.i...@gmail.com)
> wrote:
>
> Dear SPRING WG and chairs,
>
> I'd like to bring your attention to this adoption call happening in the
> RTGWG WG.
>
> The draft describes a SRv6 egress node protection mechanism in multi-home
> scen

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Huzhibo]

Hi Alvro:
Please see inline.

Thanks

Zhibo
From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Alvaro Retana
Sent: Wednesday, February 28, 2024 8:55 PM
To: Yingzhen Qu ; spring-cha...@ietf.org; Ketan 
Talaulikar 
Cc: RTGWG ; rtgwg-chairs ; 
draft-cheng-rtgwg-srv6-multihome-egress-protection 
; spring@ietf.org
Subject: Re: WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)


Hi!

Now that the terminology is a little more precise, I also looked at the 
document and found a couple of cases where SIDs are skipped by SRv6 segment 
endpoints, which is what Ketan is really concerned about (?).

These cases (see below) do not align with rfc8754 or rfc8986.  IMO, any 
proposed deviation from the existing specifications should be discussed in 
spring (for rfc8986) or 6man (for rfc8754), and formal Updates to those RFCs 
may be needed.

Thanks!

Alvaro.


(1) From §3.3 (Procedure on the Penultimate Endpoint):

   IF the primary outbound interface used to forward the packet failed
   or there is no FIB entry for forwarding the packet, the detailed
   processing to be performed by the penultimate node is as follows:

 IF SL = 1 THEN
SL decreases by 1 and becomes 0;
Update the IPv6 DA with Segment List[0];
FIB lookup on the updated DA;
Forward the packet according to the matched entry;


There seem to be two cases here: "the primary outbound interface used to 
forward the packet failed" and "there is no FIB entry for forwarding the 
packet".  I assume (?) they are grouped because the result is that there is no 
FIB entry for the destination -- IOW, the link going down results in no 
alternate path available.

rfc8754 covers this case:

   4.3.4. FIB Entry Is a No Match

  Processing is not changed by this document.


The result of a non-existent FIB entry is to drop the packet, not to forward 
it, as mentioned above.  Changing that action requires an Update to rfc8754 
(and others).

As Bruno pointed out, questions related to "how does the node know" come up.

->HZB: rfc8754 or rfc8986 only defines that Processing is not changed by 
this document. This is only a general description of the standard SRv6, not a 
mandatory specification. Of course, as you said, the new endpoint behavior 
defined in this document has been posted to the Spring group discussion.

(2) The operation described in this draft depends on P2 (Figure 3) taking on 
the role of the "Penultimate Endpoint".  But the SRH used to illustrate is "< 
A1:1::1, A2:1::A100, A3:1::B100, A4:1::B100>", which results in P2 being in the 
Segment List[2] position.

Also, PE3 also has penultimate endpoint functions in the draft.

rfc8754 and rfc8986 have explicit definitions of what the penultimate segment 
endpoint is, and the use of P2 doesn't match any of them:

rfc8754:

   Segment List[0..n]: 128-bit IPv6 addresses representing the nth
  segment in the Segment List. The Segment List is encoded starting
  from the last segment of the SR Policy. That is, the first element
  of the Segment List (Segment List[0]) contains the last segment of
  the SR Policy, the second element contains the penultimate segment
  of the SR Policy, and so on.


rfc8986:

   A PSP-flavored SID is used by the SR source node when it needs to
   instruct the penultimate SR Segment Endpoint Node listed in the SRH
   to remove the SRH from the IPv6 header.
   ...
   A penultimate SR Segment Endpoint Node is one that, as part of the
   SID processing, copies the last SID from the SRH into the IPv6
   Destination Address and decrements the Segments Left value from one
   to zero.

   The PSP operation only takes place at a penultimate SR Segment
   Endpoint Node and does not happen at any transit node. When a SID of
   PSP flavor is processed at a non-penultimate SR Segment Endpoint
   Node, the PSP behavior is not performed as described in the
   pseudocode below since Segments Left would not be zero.


There are both terminology (using "penultimate" to describe any node other than 
the one at Segment List[1]) and operation changes that would be required in 
rfc8754 and rfc8986.

-> HZB : This document does not modify the penultimate endpoint behavior. 
The P2 node described in this document is not the penultimate endpoint. We will 
modify it in the next version.
(3) From §4:

   In normal operations...The specific operations of PE3 are as follows:

   1) Remove the outer packet header and all its extension headers.

   2) Look up the FIB table according to the destination address of the
  original packet.

   3) Send the packet to CE2 according to the FIB entry.


First, much more is needed to explain the operation (codifying with pseudocode 
as all the other SRH-related operations).  The PSP flavor is specified in 
§4.16.1.2/rfc8986; it includes "S14. Update IPv6 DA 
with Segment List[Segments Left]" (not the "destination address 

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Alvaro Retana]

On March 4, 2024 at 6:46:33 AM, Huzhibo wrote:

Zhibo:

Hi!

...
> ->HZB:rfc8754 or rfc8986 only defines that Processing is not changed by
> this document. This is only a general description of the standard SRv6, not a
> mandatory specification.

rfc8754 and rfc8986 are the SRv6 specifications!  Not changing the
behavior by not forwarding packets that con't have a corresponding FIB
entry is not a suggestion, it is the expected behavior.


> ->HZB:Of course, as you said, the new endpoint behavior defined in this
> document has been posted to the Spring group discussion.

Maybe I missed that, can you please point me to the thread?



...
> -> HZB :In normal operations...The specific operations of PE3 are as
> follows,This section does not describe the PSP endpoint behavior, but the
> VPN SID endpoint behavior.We will clarify in the next version.

Note that one of the concerns is that the behavior results in some of
the SIDs being skipped, its relationship to the current standards, and
the issues that it may bring up.


Thanks!

Alvaro.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Yingzhen Qu]

Hi all,

Thank you for the comments and discussions. Based on the feedback, it has
been determined that the draft is not adopted at this time.

As discussed in the thread, the concerns raised, particularly regarding the
changes to the SRH behavior, require further discussion in the 6man and
spring working groups. We recommend that the authors address these issues
accordingly. Once resolved, the authors may consider requesting a second
adoption call if the draft remains within RTGWG.

Thanks,
Jeff and Yingzhen (RTGWG co-chairs)


On Tue, Mar 5, 2024 at 10:19 AM Alvaro Retana 
wrote:

> On March 4, 2024 at 6:46:33 AM, Huzhibo wrote:
>
> Zhibo:
>
> Hi!
>
> ...
> > ->HZB:rfc8754 or rfc8986 only defines that Processing is not changed
> by
> > this document. This is only a general description of the standard SRv6,
> not a
> > mandatory specification.
>
> rfc8754 and rfc8986 are the SRv6 specifications!  Not changing the
> behavior by not forwarding packets that con't have a corresponding FIB
> entry is not a suggestion, it is the expected behavior.
>
>
> > ->HZB:Of course, as you said, the new endpoint behavior defined in
> this
> > document has been posted to the Spring group discussion.
>
> Maybe I missed that, can you please point me to the thread?
>
>
>
> ...
> > -> HZB :In normal operations...The specific operations of PE3 are as
> > follows,This section does not describe the PSP endpoint behavior, but the
> > VPN SID endpoint behavior.We will clarify in the next version.
>
> Note that one of the concerns is that the behavior results in some of
> the SIDs being skipped, its relationship to the current standards, and
> the issues that it may bring up.
>
>
> Thanks!
>
> Alvaro.
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Weiqiang Cheng]

Dear Yingzhen and Jeff,
We sincerely appreciate the review and comments provided by all participants on 
our draft. 
As co-authors, we will carefully consider the comments and work on addressing 
the concerns raised, particularly those related to the SRH behavior changes.
Once the problems are addressed, we will consider requesting a second adoption 
call.

Best regards,
Weiqiang 

From: Yingzhen Qu
Date: 2024-03-06 15:05
To: Alvaro Retana
CC: Huzhibo; RTGWG; rtgwg-chairs; spring-cha...@ietf.org; Ketan Talaulikar; 
draft-cheng-rtgwg-srv6-multihome-egress-protection; spring@ietf.org
Subject: Re: WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)
Hi all,

Thank you for the comments and discussions. Based on the feedback, it has been 
determined that the draft is not adopted at this time.

As discussed in the thread, the concerns raised, particularly regarding the 
changes to the SRH behavior, require further discussion in the 6man and spring 
working groups. We recommend that the authors address these issues accordingly. 
Once resolved, the authors may consider requesting a second adoption call if 
the draft remains within RTGWG.

Thanks,
Jeff and Yingzhen (RTGWG co-chairs)
 

On Tue, Mar 5, 2024 at 10:19 AM Alvaro Retana  wrote:
On March 4, 2024 at 6:46:33 AM, Huzhibo wrote:

Zhibo:

Hi!

...
> ->HZB:rfc8754 or rfc8986 only defines that Processing is not changed by
> this document. This is only a general description of the standard SRv6, not a
> mandatory specification.

rfc8754 and rfc8986 are the SRv6 specifications!  Not changing the
behavior by not forwarding packets that con't have a corresponding FIB
entry is not a suggestion, it is the expected behavior.


> ->HZB:Of course, as you said, the new endpoint behavior defined in this
> document has been posted to the Spring group discussion.

Maybe I missed that, can you please point me to the thread?



...
> -> HZB :In normal operations...The specific operations of PE3 are as
> follows,This section does not describe the PSP endpoint behavior, but the
> VPN SID endpoint behavior.We will clarify in the next version.

Note that one of the concerns is that the behavior results in some of
the SIDs being skipped, its relationship to the current standards, and
the issues that it may bring up.


Thanks!

Alvaro.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[bruno . decraene]

Hi Weiqiang,

Thanks for the additional replies.
Please see inline [Bruno2]

From: Weiqiang Cheng 
Sent: Wednesday, February 28, 2024 6:59 AM
To: DECRAENE Bruno INNOV/NET ; yingzhen.ietf 

Cc: ketant.ietf ; rtgwg ; 
draft-cheng-rtgwg-srv6-multihome-egress-protection 
; rtgwg-chairs 
; spring-chairs ; spring 

Subject: Re: Re: [spring] WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

Hi Bruno and Yingzhen,
Thank you very much for your insightful comments and guidance.
Please see co-authors' feedback inline [co-author].

Thanks,
Weiqiang Cheng



From: bruno.decraene<mailto:bruno.decra...@orange.com>
Date: 2024-02-27 16:12
To: Yingzhen Qu<mailto:yingzhen.i...@gmail.com>
CC: Ketan Talaulikar<mailto:ketant.i...@gmail.com>; 
RTGWG<mailto:rt...@ietf.org>; 
draft-cheng-rtgwg-srv6-multihome-egress-protection<mailto:draft-cheng-rtgwg-srv6-multihome-egress-protect...@ietf.org>;
 rtgwg-chairs<mailto:rtgwg-cha...@ietf.org>; 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>; 
spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: [spring] WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)
Hi Yingzhen,

Thank you for your answers and clarification. That really helps.
Please see inline [Bruno]

From: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
Sent: Tuesday, February 27, 2024 3:42 AM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>
Cc: Ketan Talaulikar mailto:ketant.i...@gmail.com>>; 
RTGWG mailto:rt...@ietf.org>>; 
draft-cheng-rtgwg-srv6-multihome-egress-protection 
mailto:draft-cheng-rtgwg-srv6-multihome-egress-protect...@ietf.org>>;
 rtgwg-chairs mailto:rtgwg-cha...@ietf.org>>; 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>; 
spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

Hi Bruno,

Thank you for the feedback, really appreciate it.

Let me try to answer your questions with my understanding, and the authors 
please chime in.

Thanks,
Yingzhen

On Mon, Feb 26, 2024 at 5:07 AM 
mailto:bruno.decra...@orange.com>> wrote:
Dear Yingzhen,

At your request, I have quickly parsed the draft.

It's not completely clear to me how the solution works given that the 
terminology used is a bit loose.

2 questions on the terminology:

1) "protection" vs "restoration". The document largely uses the term 
"protection", in particular in its title. This usually assumes that protection 
is precomputed, local to the penultimate node (before the failure) and hence 
can be fast.
I'm assuming that "protection" is indeed meant. Please correct me if this is 
wrong. In which case, the node doing the protection is usually called PLR and 
is reacting before the IGP convergence. If so, it would be good for the 
document to reflect this (use the term PLR, remove the reference to IGP fast 
convergence)
(On the other hand, if would meant restoration following IGP convergence, the 
gain seems limited to me as the ingress would equally be able to react to IGP 
convergence and with PIC edge it would do it fast)
[Yingzhen]:  "Protection" is the right term.

[Bruno] OK. Therefore that’s before the IGP convergence. Could you please 
remove the references to IGP convergences?


[co-authors]  OK. We will be updated in the new version.


2) "Penultinate node" vs "penultimate Endpoint."
RFC 8754 defines different type of nodes. 
https://datatracker.ietf.org/doc/html/rfc8754#section-3
In particular, a transit node is a regular IPv6 router which does not process 
the SRH. While a EndPoint is a node receiving an IPv6 packet where the 
destination address of that packet is locally configured as a segment or local 
interface

Can you please clarify whether your Penultimate Endpoint (§3.3) is a Transit 
Node or an SR Segment Endpoint Node?

- If the Penultimate Endpoint (§3.3) is a Transit Node, then as per RFC8200 
it's not allowed to process the SRH. 
https://datatracker.ietf.org/doc/html/rfc8200#section-4 Hence your proposal 
would not be compliant with RFC 8200
- If the Penultimate Endpoint (§3.3) is an SR Segment Endpoint Node, the 
Ingress needs to specifically adds a Segment of this node. (typically End or 
End.X). If so please clarify this in the document (in particular in§3.1). Note 
that by doing so, you are adding a new point of failure (the failure of this 
Penultimate Endpoint). How do you protect from this added case of failure? If 
you don't, I would argue that the gain is debatable as you replace one type of 
failure (PE failure) by another type of failure (P failure).
[Yingzhen]: This should be "penultimate SR segment endpoint". A transit node 
may not have the capability to process a SRH. With that being said, the 
penultimate SR e

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Alexander Vainshtein]

Dear all,
A few comments:

  1.  I concur with Bruno’s latest comment about inconsistency between
 *   “Any intermediate node can bypass the failed tail node” statement by 
the draft co-authors and
 *   “This should be "penultimate SR segment endpoint”  suggested by 
Yingzhen.

  i.  I also 
concur with Bruno and Yingzhen about (1a) above being incompatible with RFC 
8200.

  1.  At the same thing I think that usage of multi-hop IP BFD for detection of 
failure of the primary egress PE by a non-adjacent "penultimate SR segment 
endpoint”  is problematic:
 *   IP BFD sessions are typically set up by specific protocols for which 
the endpoint nodes of the session are peers and that act as clients of these 
IP-BFD sessions
 *   I do not see any protocol for which the "penultimate SR segment 
endpoint”  and the egress PE are peers
  2.  Last but not least I’d like to reiterate my earlier 
request<https://mailarchive.ietf.org/arch/msg/rtgwg/cGcg5j1pxugsDMklGtI8t2icxwA/>
 to the authors to provide a detailed analysis of the trivial  but, IMHO, 
important scenario in which an BGP-based SRv6 service with best-effort 
connectivity over an underlay in which P routers only support plain IPv6 
forwarding  can benefit from the mechanism defined in the draft. (If such a 
service cannot benefit from the mechanism defined in the draft, this should be 
clearly stated).

My 2c,
Sasha

From: rtgwg  On Behalf Of bruno.decra...@orange.com
Sent: Wednesday, March 6, 2024 4:29 PM
To: Weiqiang Cheng ; yingzhen.ietf 

Cc: spring ; 
draft-cheng-rtgwg-srv6-multihome-egress-protection 
; rtgwg-chairs 
; spring-chairs ; rtgwg 

Subject: [EXTERNAL] RE: Re: [spring] WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

Hi Weiqiang,

Thanks for the additional replies.
Please see inline [Bruno2]

From: Weiqiang Cheng 
mailto:chengweiqi...@chinamobile.com>>
Sent: Wednesday, February 28, 2024 6:59 AM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>; yingzhen.ietf 
mailto:yingzhen.i...@gmail.com>>
Cc: ketant.ietf mailto:ketant.i...@gmail.com>>; rtgwg 
mailto:rt...@ietf.org>>; 
draft-cheng-rtgwg-srv6-multihome-egress-protection 
mailto:draft-cheng-rtgwg-srv6-multihome-egress-protect...@ietf.org>>;
 rtgwg-chairs mailto:rtgwg-cha...@ietf.org>>; 
spring-chairs mailto:spring-cha...@ietf.org>>; spring 
mailto:spring@ietf.org>>
Subject: Re: Re: [spring] WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

Hi Bruno and Yingzhen,
Thank you very much for your insightful comments and guidance.
Please see co-authors' feedback inline [co-author].

Thanks,
Weiqiang Cheng



From: bruno.decraene<mailto:bruno.decra...@orange.com>
Date: 2024-02-27 16:12
To: Yingzhen Qu<mailto:yingzhen.i...@gmail.com>
CC: Ketan Talaulikar<mailto:ketant.i...@gmail.com>; 
RTGWG<mailto:rt...@ietf.org>; 
draft-cheng-rtgwg-srv6-multihome-egress-protection<mailto:draft-cheng-rtgwg-srv6-multihome-egress-protect...@ietf.org>;
 rtgwg-chairs<mailto:rtgwg-cha...@ietf.org>; 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>; 
spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: [spring] WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)
Hi Yingzhen,

Thank you for your answers and clarification. That really helps.
Please see inline [Bruno]

From: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
Sent: Tuesday, February 27, 2024 3:42 AM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>
Cc: Ketan Talaulikar mailto:ketant.i...@gmail.com>>; 
RTGWG mailto:rt...@ietf.org>>; 
draft-cheng-rtgwg-srv6-multihome-egress-protection 
mailto:draft-cheng-rtgwg-srv6-multihome-egress-protect...@ietf.org>>;
 rtgwg-chairs mailto:rtgwg-cha...@ietf.org>>; 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>; 
spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

Hi Bruno,

Thank you for the feedback, really appreciate it.

Let me try to answer your questions with my understanding, and the authors 
please chime in.

Thanks,
Yingzhen

On Mon, Feb 26, 2024 at 5:07 AM 
mailto:bruno.decra...@orange.com>> wrote:
Dear Yingzhen,

At your request, I have quickly parsed the draft.

It's not completely clear to me how the solution works given that the 
terminology used is a bit loose.

2 questions on the terminology:

1) "protection" vs "restoration". The document largely uses the term 
"protection", in particular in its title. This usually assumes that protection 
is precomputed, local to the penultimate node (before the failure) and hence 
can be fast.
I'm assuming that &

Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Weiqiang Cheng]

Hi Sasha, Bruno and Alvaro,

Thank you very much for your thorough review and detailed comments. The authors 
have clearly understood your concerns. This extension is indeed related to 
several important RFCs, such as RFC8200, RFC8754 and RFC8986. The authors will 
carefully consider these factors and address your comments in the new version.

We greatly appreciate your valuable input and the time you've taken to provide 
feedback.

Best regards,
Weiqiang Cheng
 
From: Alexander Vainshtein
Date: 2024-03-06 23:31
To: bruno.decra...@orange.com; Weiqiang Cheng; yingzhen.ietf
CC: spring; draft-cheng-rtgwg-srv6-multihome-egress-protection; rtgwg-chairs; 
spring-chairs; rtgwg
Subject: Re: [spring] WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)
Dear all,
A few comments:
I concur with Bruno’s latest comment about inconsistency between 
“Any intermediate node can bypass the failed tail node” statement by the draft 
co-authors and 
“This should be "penultimate SR segment endpoint”  suggested by Yingzhen. 
  i.  I also 
concur with Bruno and Yingzhen about (1a) above being incompatible with RFC 
8200.
At the same thing I think that usage of multi-hop IP BFD for detection of 
failure of the primary egress PE by a non-adjacent "penultimate SR segment 
endpoint”  is problematic:
IP BFD sessions are typically set up by specific protocols for which the 
endpoint nodes of the session are peers and that act as clients of these IP-BFD 
sessions
I do not see any protocol for which the "penultimate SR segment endpoint”  and 
the egress PE are peers
Last but not least I’d like to reiterate my earlier request to the authors to 
provide a detailed analysis of the trivial  but, IMHO, important scenario in 
which an BGP-based SRv6 service with best-effort connectivity over an underlay 
in which P routers only support plain IPv6 forwarding  can benefit from the 
mechanism defined in the draft. (If such a service cannot benefit from the 
mechanism defined in the draft, this should be clearly stated).
 
My 2c,
Sasha
 
From: rtgwg  On Behalf Of bruno.decra...@orange.com
Sent: Wednesday, March 6, 2024 4:29 PM
To: Weiqiang Cheng ; yingzhen.ietf 

Cc: spring ; 
draft-cheng-rtgwg-srv6-multihome-egress-protection 
; rtgwg-chairs 
; spring-chairs ; rtgwg 

Subject: [EXTERNAL] RE: Re: [spring] WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)
 
Hi Weiqiang,
 
Thanks for the additional replies.
Please see inline [Bruno2]
 
From: Weiqiang Cheng  
Sent: Wednesday, February 28, 2024 6:59 AM
To: DECRAENE Bruno INNOV/NET ; yingzhen.ietf 

Cc: ketant.ietf ; rtgwg ; 
draft-cheng-rtgwg-srv6-multihome-egress-protection 
; rtgwg-chairs 
; spring-chairs ; spring 

Subject: Re: Re: [spring] WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)
 
Hi Bruno and Yingzhen,
Thank you very much for your insightful comments and guidance.
Please see co-authors' feedback inline [co-author]. 
 
Thanks,
Weiqiang Cheng
 
 
 
From: bruno.decraene
Date: 2024-02-27 16:12
To: Yingzhen Qu
CC: Ketan Talaulikar; RTGWG; 
draft-cheng-rtgwg-srv6-multihome-egress-protection; rtgwg-chairs; 
spring-cha...@ietf.org; spring@ietf.org
Subject: Re: [spring] WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)
Hi Yingzhen,
 
Thank you for your answers and clarification. That really helps.
Please see inline [Bruno]
 
From: Yingzhen Qu  
Sent: Tuesday, February 27, 2024 3:42 AM
To: DECRAENE Bruno INNOV/NET 
Cc: Ketan Talaulikar ; RTGWG ; 
draft-cheng-rtgwg-srv6-multihome-egress-protection 
; rtgwg-chairs 
; spring-cha...@ietf.org; spring@ietf.org
Subject: Re: WG Adoption Call - 
draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)
 
Hi Bruno,
 
Thank you for the feedback, really appreciate it.
 
Let me try to answer your questions with my understanding, and the authors 
please chime in.
 
Thanks,
Yingzhen
 
On Mon, Feb 26, 2024 at 5:07 AM  wrote:
Dear Yingzhen,

At your request, I have quickly parsed the draft.

It's not completely clear to me how the solution works given that the 
terminology used is a bit loose.

2 questions on the terminology:

1) "protection" vs "restoration". The document largely uses the term 
"protection", in particular in its title. This usually assumes that protection 
is precomputed, local to the penultimate node (before the failure) and hence 
can be fast.
I'm assuming that "protection" is indeed meant. Please correct me if this is 
wrong. In which case, the node doing the protection is usually called PLR and 
is reacting before the IGP convergence. If so, it would be good for the 
document to reflect this (use the term PLR, remove the reference to IGP fast 
convergence)
(On the other hand, if would meant restoration following IGP converg