Can we incorporate this in draft.
Juniper Business Use Only From: spring <spring-boun...@ietf.org> On Behalf Of Rajesh M Sent: Tuesday, September 1, 2020 5:57 PM To: Ketan Talaulikar (ketant) <ketant=40cisco....@dmarc.ietf.org>; 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 [External Email. Be cautious of content] May be I was not very clear. My only ask is we must Recommended "BGP next hop and SRV6 service SID for a BGP route must be derived from the same locator" So that we no need to check the reachability to BGP nexthop and then check the reachability to SRV6 service SID >From the draft section >"5<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bess-srv6-services-04*section-5__;Iw!!NEt6yMaO-gk!QThactTaAPErZ-MS1mmVVhdT3QwOFTVodHD8AiFZbpYeBHwg5tc7lFraAxixSZsG$>. > 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. 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<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bess-srv6-services-04__;!!NEt6yMaO-gk!VFBL5EymnOFcbdSKcT94LIq7IazTJ_5iSmOPnY1yZllaYoKwJL934-OIYpdvFakr$> [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
