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

[Gurusiddesh Nidasesi <[e-mail]>]

Hi Ketan,

Thanks for the response.
Additionally, we have more queries as follows:


The draft says that
"One or more IPv4 address format route-target extended community

      ([RFC4360 <https://tools.ietf.org/html/rfc4360>]) attached to
the SR Policy advertisement and that

      indicates the intended head-end of such SR Policy advertisement."

Here one or more RTs are attached to match specific headend?

" If one or more route-targets are present, then at least one route  target
MUST match one of the BGP Identifiers of the receiver in order  for the
update to be considered usable."
Can a BGP peer have more than one BGP identifier?


On Wed, Jul 3, 2019 at 7:29 PM Ketan Talaulikar (ketant) <[e-mail]>
wrote:

> Hi Gurusiddesh,
>
>
>
> The purpose of the RT is to indicate the specific headend for which the SR
> Policy is for. So I am not sure of the scenario where multiple RTs will be
> associated with a single update.
>
>
>
> Even if it were, I am not sure we normally strip out RTs automatically
> without some specific route policy being applied.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Gurusiddesh Nidasesi <[e-mail]>
> *Sent:* 26 June 2019 12:56
> *To:* Ketan Talaulikar (ketant) <[e-mail]>
> *Cc:* Chaitanya Varma <[e-mail]>; [e-mail];
> Ramanathan Selvamani <[e-mail]>
> *Subject:* Re: [Idr] Mail regarding
> draft-ietf-idr-segment-routing-te-policy
>
>
>
> 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
>
>
> .
>


-- 
Thanks,
Gurusiddesh V N

-- 
.