Re: [bess] SRV6 for EVPN Fast Reroute

[linchangwang <[e-mail]>]

Hi Luc,

Theirs is another way of achieving the same thing - using the behavior vs. using the flag.
The draft link:  https://datatracker.ietf.org/doc/draft-liu-bess-multihome-srv6-service-sid-flag/

Each egress PE advertises an additional SRv6 Service SID in BGP
routes which is called No-Further-FRR SID.

The owner of No-Further-FRR SID will not provide local FRR for it.
  When the next-hop of No-Further-FRR SID is down, like PE-CE link
  failure or CE node failure, the PE will drop packets rather than
  apply FRR.

 The No-Further-FRR SID can used by other PE as the protection of
   local PE-CE link failure, without worrying about the looping
   problem.

This draft defines no-further-FRR flag in the SRv6 Service SID Flags
   field of the SRv6 SID Information Sub-TLV [RFC9252]:



    0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | SRv6 Service  |    SRv6 Service               |               |

   | Sub-TLV       |    Sub-TLV                    |               |

   | Type=1        |    Length                     |  RESERVED1    |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |  SRv6 SID Value (16 octets)                                  //

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | Svc SID Flags |   SRv6 Endpoint Behavior      |   RESERVED2   |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |  SRv6 Service Data Sub-Sub-TLVs                              //

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



     Svc SID Flags:



      0 1 2 3 4 5 6 7

     +-+-+-+-+-+-+-+-+

     |N|A|           |

     +-+-+-+-+-+-+-+-+



   o N-flag: No-Further-FRR flag. When set, the associated SID has no

      fast reroute protection.

The differences between the draft [https://datatracker.ietf.org/doc/html/draft-burdet-bess-evpn-fast-reroute-06<https://urldefense.com/v3/__https:/ai.h3c.com/redirect?target=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-burdet-bess-evpn-fast-reroute-06__;JSUlJSUl!!NEt6yMaO-gk!BbBdHr7voVCInshbrsekYTjmCOpVIvSkGCSVsCSiEKNopTiVAeTTebr7ssc3v1UIbpiTOmFd7eGEZXH0CiWDHXbGYYQ$>] and the  draft
[https://datatracker.ietf.org/doc/draft-liu-bess-multihome-srv6-service-sid-flag/] are as follows:


*  The focus of the "evpn fast reroute" draft is solely on FRR in the EVPN scenario, specifically for L2VPN scenarios.

*  In contrast, this draft [draft-liu-bess-multihome-srv6-service-sid-flag] is applicable to both L3VPN and L2VPN networking.

*  This draft [draft-liu-bess-multihome-srv6-service-sid-flag] does not require any additional definition of "Flavor". It only involves local behavior and does not require service SID flavor expansion.

*  The "evpn fast reroute" draft requires the use of arg to solve DF (Designated Forwarder) problems. However, if arg is used for other applications in the future, it may no longer be available for use in this context.

*  This draft [draft-liu-bess-multihome-srv6-service-sid-flag] only provides a brief expansion on the definition of the "flag" and it is applicable to both L2VPN and L3VPN scenarios.

I would like to mention that there is an alternative approach to achieving the same objective - using a flag instead of introducing a new flavor. I believe that not using Fast-re-route can be considered a local action.
By notifying the ingress node through a flag, there would be no need to define new flavors for DT4, DT6, DT2U, and DX2.
Additional feedback and suggestions are welcome.

Thanks,
Changwang



From: spring [mailto:[e-mail]] On Behalf Of Luc André Burdet
Sent: Thursday, September 07, 2023 12:25 AM
To: [e-mail]
Subject: [spring] SRV6 for EVPN Fast Reroute

SPRING WG,

My co-authors and myself have presented a document in BESS WG which describes fast convergence in EVPN networks without relying on control plane actions. In the latest version SRV6 support was introduced.

https://datatracker.ietf.org/doc/draft-burdet-bess-evpn-fast-reroute/

The draft specifies two forwarding behaviours which must be implemented:

  *   "Terminal disposition" to prevent loops, esp. in EVPN's All-Active (MLAG) case
  *   "DF-Bypass" to address the dropping of rerouted packets on blocked ports until control-plane catches up (BGP route withdraw)

For SRV6, these are mapped to 2 proposed new behaviours (variants of existing behaviours) both taking optional Args
- End.DT2U.Reroute : End.DT2U with Fast Reroute
- End.DX2.Reroute : End.DX2 with Fast Reroute

The authors would appreciate feedback and any comments on the SRV6 proposal contained in the document

Regards,
Luc André

Luc André Burdet |  Cisco  |  [e-mail]  |  Tel: [phone]

-------------------------------------------------------------------------------------------------------------------------------------
???????????????????,?????????????
?????????????????????(??????????????????
???)?????????????????,??????????????????
??!
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!