A new Request for Comments is now available in online RFC libraries.
RFC 9081
Title: Interoperation between Multicast Virtual Private
Network (MVPN) and Multicast Source Directory
Protocol (MSDP) Source-Active Routes
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
Hi All,
Please find final agenda for IETF 111. Individuals, please send slides to me
unicast.
https://datatracker.ietf.org/meeting/111/materials/agenda-111-bess-01
We had request more than open slot. We have tried to accommodate most of it.
Mankamana
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
Title : Gateway Auto-Discovery and Route Advertisement for
Segment Routing Enabled Site Interconnection
Authors
Hi again,
> COMMENT:
>
>
> The -12 does address the discuss point that I raised, thank you!
>
> In re-reading the draft so as to clear my discuss position, one thing
> that occurred to me is that a reader might wonder what
On Thu, Jul 22, 2021 at 07:12:50PM +0100, Adrian Farrel wrote:
> > Picking up (belatedly) where I left off in my initial reply...
>
> Thanks, Ben.
>
> >>> Section 5
> >>>
> >>> for a prefix X, then each GW computes an SR TE path through that site
> >>> to X from each of the currently active
> Picking up (belatedly) where I left off in my initial reply...
Thanks, Ben.
>>> Section 5
>>>
>>> for a prefix X, then each GW computes an SR TE path through that site
>>> to X from each of the currently active GWs, and places each in an
>>> MPLS label stack sub-TLV [RFC9012] in the SR
Ketan,
"In some cases a service prefix intending to use flex-algo paths may want
fallback on
best effort paths when a flex-algo path isn't available. The fallback behavior
SHOULD be governed by local policies.
The destination address SHOULD contain the best-effort locator based END SID
of
Dear all :
I'd like to share experience and get feedback on some common problems related
to host address detection, and how to solve those. Starting with what we often
refer to as silent nodes, and the corollary DDoS attacks on addresses that are
not effectively present in a very large subnet.
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,
As clarified a short while ago on the same thread, the draft talks about two
SRv6-based transport mechanisms. I believe your comments are not related to the
SR Policy based steering mechanisms. We already have mechanisms defined for
fallback in that case.
Since the draft is
Resending with individual email addressed trimmed
From: Ketan Talaulikar (ketant)
Sent: 22 July 2021 13:13
To: Rajesh M ; Rajesh M
; Rabadan, Jorge (Nokia - US/Mountain
View) ; gdawra.i...@gmail.com; Clarence Filsfils
(cfilsfil) ; rob...@raszuk.net; bruno.decra...@orange.com
Cc:
Hi Swadesh,
This I understood by going through the draft thoroughly. But definitely more
clarification is better as you pointed.
1) So SRv6 SID TLV is used only to carry variable part ? it will never carry
complete SID ?
2) Is there any case where we carry a complete SID1 in prefix SID
19 matches
Mail list logo
