Hi Eduard, I see your point and we’ll clarify this in the next update.
Thanks, Ketan From: Eduard Metz <etm...@gmail.com> Sent: 25 May 2021 18:08 To: Robert Raszuk <rob...@raszuk.net> Cc: Rajesh M <mraj...@juniper.net>; bruno.decra...@orange.com; spring@ietf.org; Ketan Talaulikar (ketant) <ket...@cisco.com>; Clarence Filsfils (cfilsfil) <cfils...@cisco.com>; gdawra.i...@gmail.com Subject: Re: [spring] https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services For my understanding, draft-ietf-bess-srv6-services describes this (ch 6): " When providing best-effort connectivity to the egress PE, the ingress PE encapsulates the payload in an outer IPv6 header where the destination address is the SRv6 Service SID associated with the related BGP route update. Therefore, the ingress PE SHOULD perform resolvability check for the SRv6 Service SID before considering the received prefix for the BGP best path computation. " and this, " When the BGP route received at an ingress PE is colored with an extended color community and is being steered over a valid SRv6 Policy associated with SID list <S1, S2, S3> as described in Section 8 of [I-D.ietf-spring-segment-routing-policy], then the effective SR Policy is <S1, S2, S3-Service-SID>. " To map two different prefixes to a different FlexAlgo you could either: - Select different Service SIDs for the prefixes taken from the respective locators associated with the different FlexAlgo's. The ingress will apply a "default" policy and use the advertised Service SID as destination address. - Select the same SID for the prefixes and color the routes differently. The policy on the ingress then determines the (additional) SID to be applied to the packets. Correct? Which one to choose is a matter of architecture / design of the network (and its services), there are tradeoffs that may be different for an operator. In both cases it would be 'per VRF' SIDs If both are valid, this text: " When providing best-effort connectivity to the egress PE, the ingress PE encapsulates the payload in an outer IPv6 header where the destination address is the SRv6 Service SID associated with the related BGP route update." May be changed to something along these lines: " When no additional policy applies to the connectivity to the egress PE, the ingress PE encapsulates the payload in an outer IPv6 header where the destination address is the SRv6 Service SID associated with the related BGP route update. To reflect "default behaviour" vs other (based on policy), instead of best-effort vs policy. cheers, Eduard On Tue, May 18, 2021 at 5:14 PM Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> wrote: Hi Rajesh, I am afraid you are mixing layers :) VRF services can be mapped to any color for transport and that color does not need to be subject to PHP. Flexible Algorithm are layer below services and are just about transport in the set of closed domains. If you look at https://datatracker.ietf.org/doc/html/draft-hegde-spring-mpls-seamless-sr-02 page 14 this should be clear that IL red/blue color label can be carried to the egress PE and data can be treaded as red/blue also when traversing such egress PEs. We do not need in general to explode service label space/sid. Thx, Robert. On Tue, May 18, 2021 at 4:03 PM Rajesh M <mraj...@juniper.net<mailto:mraj...@juniper.net>> wrote: Thanks Ketan, My query is If we allocate SRv6 Service SID per-VRF Let’s assume For this VRF locator assigned is 2001:129:1:13:: DT4 SID is-2001:129:1:13::4 DT6 SID is - 2001:129:1:13::6 a) Now how to support Different flex algo for different routes with in a VRF ? For VRF1 Prefix 10.129.0.0 I want to use color 129…this is OK * BGP Prefix: 10.129.0.0/16<http://10.129.0.0/16> * color: 129 * Service SID: 2001:129:1:13::4 (DT4 SID) For VRF1 Prefix 10.128.0.0 I want to use color 128 * Prefix: 10.128.0.0/16<http://10.128.0.0/16> * color: 128 * Service SID: ? (I don’t have service SID based upon color 128, since above allocation is based upon per vrf) Thanks Rajesh Juniper Business Use Only From: Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>> Sent: Tuesday, May 18, 2021 5:35 PM To: Rajesh M <mraj...@juniper.net<mailto:mraj...@juniper.net>>; gdawra.i...@gmail.com<mailto:gdawra.i...@gmail.com>; Clarence Filsfils (cfilsfil) <cfils...@cisco.com<mailto:cfils...@cisco.com>>; rob...@raszuk.net<mailto:rob...@raszuk.net>; bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; spring@ietf.org<mailto:spring@ietf.org> Subject: RE: https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services [External Email. Be cautious of content] Hi Rajesh, The FlexAlgo for SRv6 is described in https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/__;!!NEt6yMaO-gk!Xn4WAWuXx98Jdyu7VzfkC3hjctbWJEnPiTUcj_bAML3F17iJrr77ruwLY3XyBBXQ$> and that would require different SRv6 Locators for the FlexAlgo. When the SRv6 Service SID is allocated from the SRv6 Locator for a FlexAlgo then the service flow will be forwarded along with FlexAlgo path. I am not entirely sure that I got your question though. Thanks, Ketan From: Rajesh M <mraj...@juniper.net<mailto:mraj...@juniper.net>> Sent: 17 May 2021 12:30 To: gdawra.i...@gmail.com<mailto:gdawra.i...@gmail.com>; Clarence Filsfils (cfilsfil) <cfils...@cisco.com<mailto:cfils...@cisco.com>>; Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>; rob...@raszuk.net<mailto:rob...@raszuk.net>; bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; spring@ietf.org<mailto:spring@ietf.org> Subject: https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services Hi All, As per draft “When providing best-effort connectivity to the egress PE, the ingress PE encapsulates the payload in an outer IPv6 header where the destination address is the SRv6 Service SID associated with the related BGP route update.” If we allocate SRv6 Service SID per-VRF then how to support a) Different flex algo with in a VRF ? b) Different flex algo with in a internet (default VRF or global) Thanks Rajesh Juniper Business Use Only _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
