Re: [Idr] Mail regarding draft-ietf-idr-segment-routing-te-policy

[Gurusiddesh Nidasesi <[e-mail]>]

Hi Ketan,

We have some more doubts as follows:

"Typically, a controller defines the set of policies and advertise
   them to policy head-end routers (typically ingress routers).  The
   policy advertisement uses BGP extensions defined in this document.
   The policy advertisement is, in most but not all of the cases,
   tailored for a specific policy head-end.  In this case the
   advertisement may sent on a BGP session to that head-end and not
   propagated any further."


If controller sends multiple unique RTs in the same Update message,
1. Once the SR policy reaches the Headend, should we strip down that
particular RT to avoid advertising it further?


Thanks
Gurusiddesh V N



On Wed, May 8, 2019 at 3:58 PM Ketan Talaulikar (ketant) <[e-mail]>
wrote:

> Hi Gurusiddesh,
>
>
>
> Please check inline below
>
>
>
> *From:* Gurusiddesh Nidasesi <[e-mail]>
> *Sent:* 07 May 2019 17:11
> *To:* Ketan Talaulikar (ketant) <[e-mail]>
> *Cc:* Chaitanya Varma <[e-mail]>; [e-mail]
> *Subject:* Re: [Idr] Mail regarding
> draft-ietf-idr-segment-routing-te-policy
>
>
>
> Hi Ketan,
>
>
>
> Thanks for the quick response.
>
> Additionally, we have more queries as follows
>
>
>
> *"Alternatively, a router (i.e., a BGP egress router) advertises SR*
>
> *   Policies representing paths to itself.  In this case, it is possible*
>
> *   to send the policy to each head-end over a BGP session to that head-*
>
> *  end, without requiring any further propagation of the policy."*
>
>
>
> How does an egress router advertise SR policies representing paths to
> itself?
>
> *[KT] By setting endpoint to it’s own router-id in the NLRI and setting
> the ingress router’s router-id in the router-target extended community.*
>
> Is it done through BGP configuration or any other trigger?
>
> *[KT] This would be implementation specific based on the
> use-case/workflow.*
>
>
> In the above case how ERO (SID-List) is calculated?
>
> *[KT] This is again implementation specific. It could be done by some TE
> module on the egress BGP router that has topology visibility from the
> ingress router to itself. It would be kind of reverse of how a headend
> computes a path from itself to an endpoint – this is the endpoint computing
> path to itself from some headend.*
>
> *Thanks,*
>
> *Ketan*
>
>
>
> Regards
>
> Gurusiddesh V N
>
>
>
> On Wed, May 1, 2019 at 7:34 PM Ketan Talaulikar (ketant) <[e-mail]>
> wrote:
>
> Hi Chaitanya,
>
>
>
> Please check inline below.
>
>
>
> *From:* Idr <[e-mail]> *On Behalf Of *Chaitanya Varma
> *Sent:* 30 April 2019 13:34
> *To:* [e-mail]
> *Cc:* Gurusiddesh Nidasesi <[e-mail]>
> *Subject:* [Idr] Mail regarding draft-ietf-idr-segment-routing-te-policy
>
>
>
> Hi,
>
>
>
> I have couple of queries from the below draft.
>
>
>
> https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05
>
>
>
> *  “ Typically, a controller defines the set of policies and advertise*
>
> *   them to policy head-end routers (typically ingress routers).” *
>
>
>
> How do we communicate SR policies from controller? Is it through BGP-SR
> session or PCEP session.
>
> *[KT] This draft is all about using BGP for signalling SR Policies from a
> controller to the head-end routers. So yes (b) below.*
>
>
>
> a. If it is through PCEP session what happens if the PCC is non-headend?
>
> b. If it is through BGP-SR what is the role for PCEP between PCE and PCC?
>
> *[KT] PCEP is another flavour for instantiation of SR Policies. Yet
> another option is using netconf/yang or another method for provisioning.
> This draft is about using BGP and PCEP is not required.*
>
>
>
> *  “ Moreover, one or more route-target SHOULD be attached to the*
>
>
>
> *   advertisement” *How Route-target should be attached to a SR-NLRI
> update?
>
> *[KT] As Route Target Extended Communities attribute – ref sec 1 of the
> draft.*
>
>
>
> Is it done through local configuration or picked up based on some dynamic
> parameter?
>
> *[KT] It is done by the controller and may be done via local config –
> either along with the SR Policy or route policy or even dynamically based
> on the head-end address. This would be implementation specific.*
>
>
>
> *Thanks,*
>
> *Ketan*
>
>
>
> Appreciate if you can help here.
>
>
>
>
>
> Regards,
>
> Chaitanya
>
>
>
>
> ..
>
>
>
>
> --
>
> Thanks,
>
> Gurusiddesh V N
>
>
> .
>


-- 
Thanks,
Gurusiddesh V N

-- 
.