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:spring-boun...@ietf.org] On Behalf Of Luc André Burdet
Sent: Thursday, September 07, 2023 12:25 AM
To: spr...@ietf.org
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 | laburdet.i...@gmail.com | Tel: +1 613 254 4814
-------------------------------------------------------------------------------------------------------------------------------------
???????????????????,?????????????
?????????????????????(??????????????????
???)?????????????????,??????????????????
??!
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!
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
