Hi Shraddha
I agree the fallback mechanisms are important to operators but as there are
many complex scenarios related to fallback and some of which include SRv6
to SR-MPLS interworking, I agree that this is important and as such can be
captured in a separate document that defines all the
Hi Ketan,
When the BGP route received at an ingress PE is colored with an
extended color community and is being steered over a valid SRv6
Policy associated with SID list as described in
Section 8 of
IMO we could add to the draft a statement that implementation MUST/SHOULD
support fallback to any available forwarding plane. But I am not sure if
this will not turn out against some implementations which may have problem
with that.
Order of such fallback is a policy/cfg decision.
Likewise
Hi Salih,
The preference for steering over SR Policy applies to both SR-MPLS and SRv6. So
we are covered from that perspective.
I get the impression that this email discussion thread about “fallback” is
about when sending over a non-SR Policy based steering mechanism. That too, I
get the
Thanks, Ketan.
This indicates a preference for steering over SR Policy while using color
extended community.
Then specify color only bits etc modes for specifying fallbacks if required.
Currently it doesn’t talk about flex (but mention mostly IGP path to the
next-hop N) and hence it need not
Hi Rajesh,
I think there might be some confusion here with the mix-up between a draft
which is past WGLC and an individual draft? Would it be possible to keep their
discussions on separate threads?
However, since I am an author on both, I would like to clarify is that "the
rules" are merely
Hi Ketan,
As per CAR draft - For Intent service Route (IGP Flex-Algo first then BGP CAR
then SR Policy):
So below must be the rules right ?
BGP next hop is not reachable return (just for reachability).
Resolve SRv6 Service SID for forwarding(To find IGP flex algo).if successfully
resolves then
Hi Salih,
Could you please check the following regarding the choice/fallback when using
SR Policy based steering?
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13#section-8.4
Hi Ketan,
1 clarification query:
With flex algo and SRTE policies, service routes can carry color extended
communities.
Now for the ingress, how to decide whether to resolve over SRv6 Service SID (to
choose flex algo) OR over BGP Protocol next hop (to choose SRTE)?
In a domain both can be
Hi Shraddha,
do you agree this is about switching between shortest path (in base topology or
flex-algo topology) and SRv6 policy?
You can describe a fallback strategy but the need to resolve or not the service
SID is orthogonal and is only dictated by the use of shortest path forwarding
or
I agree with Jim that fallback needs to be discussed in the draft .
The current draft mandates the resolvability of the service SID. The fact that
when flex-algo is allowed to
Fallback to best effort, service SID resolvability is not required because
service SID corresponds to flex-algo
Comments In-Line..
Thanks,
Jim Uttaro
From: spring On Behalf Of Aissaoui, Mustapha (Nokia -
CA/Ottawa)
Sent: Tuesday, July 20, 2021 1:14 PM
To: Srihari Sangli ; Shraddha Hegde
; Robert Raszuk
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay
Hi Srihari,
I am not able to find the text about fallback in the version 07 of the draft. I
may have misunderstood but I thought Shraddha was proposing new text to cover
fallback in the draft.
The draft refers to “SRv6 service with best-effort connectivity” and to “SRv6
service in conjunction
Mustapha,
I think Shraddha is pointing about the paragraph “When providing best-effort
connectivity…” where it specifically talks about fallback to best-effort and if
so, perform the resolvability check on the service-SID. Going by what you are
saying that its general behavior of SRv6 policy,
14 matches
Mail list logo
