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 <robert@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 <mrajesh@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
>>    - 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
>>    - 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) <ketant@cisco.com>
>> *Sent:* Tuesday, May 18, 2021 5:35 PM
>> *To:* Rajesh M <mrajesh@juniper.net>; gdawra.ietf@gmail.com; Clarence
>> Filsfils (cfilsfil) <cfilsfil@cisco.com>; robert@raszuk.net;
>> bruno.decraene@orange.com; 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 <mrajesh@juniper.net>
>> *Sent:* 17 May 2021 12:30
>> *To:* gdawra.ietf@gmail.com; Clarence Filsfils (cfilsfil) <
>> cfilsfil@cisco.com>; Ketan Talaulikar (ketant) <ketant@cisco.com>;
>> robert@raszuk.net; bruno.decraene@orange.com; 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
> https://www.ietf.org/mailman/listinfo/spring
>