Hi, I fully agree with Ketan. For (a), it is obvious that if the next-hop and locator belong to the same prefix, we minimize the prefixes to be advertised, hence we’ll have smaller route tables. But it is up to the user to decide that. The spec should support both.
Similar for (b). There may be multiple locators on the same router. Thanks. Jorge From: Ketan Talaulikar (ketant) <ket...@cisco.com> Date: Thursday, August 27, 2020 at 9:06 AM To: Rajesh M <mrajesh=40juniper....@dmarc.ietf.org>, gdawra.i...@gmail.com <gdawra.i...@gmail.com>, Clarence Filsfils (cfilsfil) <cfils...@cisco.com>, rob...@raszuk.net <rob...@raszuk.net>, bruno.decra...@orange.com <bruno.decra...@orange.com>, zhuangshun...@huawei.com <zhuangshun...@huawei.com>, Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com> Cc: spring@ietf.org <spring@ietf.org> Subject: RE: https://tools.ietf.org/html/draft-ietf-bess-srv6-services-04 Hi Rajesh, Please check inline below. From: spring <spring-boun...@ietf.org> On Behalf Of Rajesh M Sent: 27 August 2020 12:26 To: gdawra.i...@gmail.com; Clarence Filsfils (cfilsfil) <cfils...@cisco.com>; rob...@raszuk.net; bruno.decra...@orange.com; zhuangshun...@huawei.com; jorge.raba...@nokia.com Cc: spring@ietf.org Subject: Re: [spring] https://tools.ietf.org/html/draft-ietf-bess-srv6-services-04 Sending it again. Juniper Business Use Only From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> On Behalf Of Rajesh M Sent: Saturday, August 22, 2020 8:43 AM To: gdawra.i...@gmail.com<mailto:gdawra.i...@gmail.com>; cfils...@cisco.com<mailto:cfils...@cisco.com>; rob...@raszuk.net<mailto:rob...@raszuk.net>; bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; zhuangshun...@huawei.com<mailto:zhuangshun...@huawei.com>; jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com> Cc: spring@ietf.org<mailto:spring@ietf.org> Subject: [spring] https://tools.ietf.org/html/draft-ietf-bess-srv6-services-04 [External Email. Be cautious of content] 5<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bess-srv6-services-04*section-5__;Iw!!NEt6yMaO-gk!TZ1_c_CakbKuEYdXL_Wr1E0qNsD9LbXA6HMU_M2DQIT4UfAIr09QXsIIcfyxDZIY$>. BGP based L3 service over SRv6 When the egress PE sets the next-hop to a value that is not covered by the SRv6 Locator from which the SRv6 Service SID is allocated, then the ingress PE SHOULD perform reachability check for the SRv6 Service SID in addition to the BGP next-hop reachability procedures. I think we should mention, few points for egress side a) Recommended to set the bgp nexthop based upon locator. [KT] I would think that it is difficult to normatively recommend such a thing in the spec. There would be implementation and deployment design aspects to be considered. b) All the service SIDs across vrfs(DT4,DT6...) must be derived from the same locator (this is independent of setting bgp nexthop) [KT] I am not sure such a restriction is required and in fact would be severely limiting in nature. Consider that some service may wish to leverage a FlexAlgo based on delay metric computation to get from the ingress to egress PE. In such cases, the egress PE can allocate the SRv6 SID for that service from its FlexAlgo specific locator. Thanks, Ketan Juniper Business Use Only
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
