ert Raszuk ; SPRING WG <
> spring@ietf.org>; draft-ietf-spring-segment-routing-pol...@ietf.org; idr
> wg ; stefano previdi
> *Subject:* Re: [spring] [Idr] Comments: Route Origin Community in SR
> Policy(draft-ietf-spring-segment-routing-policy)
>
>
>
>
>
> Ketan
>
Talaulikar (ketant)
; Robert Raszuk ; SPRING WG
; draft-ietf-spring-segment-routing-pol...@ietf.org; idr wg
; stefano previdi
Subject: Re: [spring] [Idr] Comments: Route Origin Community in SR
Policy(draft-ietf-spring-segment-routing-policy)
Ketan
Thanks for sharing this draft.
This draft
Ketan
Thanks for sharing this draft.
This draft below is the SR-TE policy itself but the piece I was missing was
the BGP interaction between SR-TE and new SAFI to advertise SR-TE policy
into BGP which is the critical component of the per VRF coloring schema to
steer L3 vpn traffic.
https://datat
Hi Ketan,
Sorry for my delay, I saw the update, and it has addressed my comments, many
thanks.
Best,
Cheng
From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Monday, May 18, 2020 8:00 PM
To: Robert Raszuk
Cc: Chengli (Cheng Li) ;
draft-ietf-spring-segment-routing-pol...@ietf.org
Hi Robert,
You are right that the “Originator” is not used in BGP best path and is just
for a tie-breaking logic in SRTE between paths from different protocols and
controllers. I doubt if there is a functional issue here.
I thought that Chengli was bringing in some new/different requirement for
Hi Chengli and Ketan,
Well I think (perhaps to your surprise) the current text is actually
correct.
See the overall idea of section 2.4 is not to define the real source of the
candidate path. That is done in section 2.5 The idea here is to keep
multiple *paths or versions* of the candidate paths
