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

Hi Ketan,
Maybe it makes sense to reword this a little bit? The point about multiple
RTs in the update is fine, but the confusion probably stems from "match one
of the BGP identifiers"
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
   to
If one or more route-targets are present, then at least one route  target
MUST match the BGP Identifier of the receiver in order

Thanks,
Nandan
On Mon, Jul 8, 2019 at 10:46 AM Ketan Talaulikar (ketant) <ketant@cisco.com>
wrote:

> Hi Gurusiddesh,
>
>
>
> The reason for allowing multiple RTs is if the same SR Policy needs to be
> delivered to multiple headend routers. It need not be read as a BGP router
> having more than one BGP identifier.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Gurusiddesh Nidasesi <gurusiddesh.nidasesi@ipinfusion.com>
> *Sent:* 08 July 2019 10:09
> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>
> *Cc:* Chaitanya Varma <chaitanya.varma@ipinfusion.com>; idr@ietf.org;
> Ramanathan Selvamani <ramanathan.selvamani@ipinfusion.com>
> *Subject:* Re: [Idr] Mail regarding
> draft-ietf-idr-segment-routing-te-policy
>
>
>
> 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) <ketant@cisco.com>
> 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 <gurusiddesh.nidasesi@ipinfusion.com>
> *Sent:* 26 June 2019 12:56
> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>
> *Cc:* Chaitanya Varma <chaitanya.varma@ipinfusion.com>; idr@ietf.org;
> Ramanathan Selvamani <ramanathan.selvamani@ipinfusion.com>
> *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) <ketant@cisco.com>
> wrote:
>
> Hi Gurusiddesh,
>
>
>
> Please check inline below
>
>
>
> *From:* Gurusiddesh Nidasesi <gurusiddesh.nidasesi@ipinfusion.com>
> *Sent:* 07 May 2019 17:11
> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>
> *Cc:* Chaitanya Varma <chaitanya.varma@ipinfusion.com>; idr@ietf.org
> *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) <ketant@cisco.com>
> wrote:
>
> Hi Chaitanya,
>
>
>
> Please check inline below.
>
>
>
> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of *Chaitanya Varma
> *Sent:* 30 April 2019 13:34
> *To:* idr@ietf.org
> *Cc:* Gurusiddesh Nidasesi <gurusiddesh.nidasesi@ipinfusion.com>
> *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
>
>
> .
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>