Re: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

["Ketan Talaulikar (ketant)" <[e-mail]>]

Hi Rajesh,

When the Ingress PE is not doing steering over SR Policy, that includes both best-effort (algo 0) or flex-algo, the following takes place. Please note the update pending [1].

   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.

The question in your email below was about Ingress PE doing steering over SR Policy and there the SR Policy endpoint is the BGP NH.

Thanks,
Ketan

[1] https://mailarchive.ietf.org/arch/msg/spring/tvaIzbCUtE_dJxrxGVsFadpTpAk/


From: Rajesh M <[e-mail]>
Sent: 01 July 2021 12:56
To: Ketan Talaulikar (ketant) <[e-mail]>; [e-mail]; Clarence Filsfils (cfilsfil) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)


Thanks Ketan. For flex algo scenario,

Resolution we must do using BGP next hop  or srv6 service sid (here srv6 service sid is derived from the corresponding flex algo locator) ?
These are all very important to know for interop.

Thanks
Rajesh




Juniper Business Use Only
From: Ketan Talaulikar (ketant) <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, July 1, 2021 10:53 AM
To: Rajesh M <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Clarence Filsfils (cfilsfil) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Hi Rajesh,

Per https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13#section-8.4<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13*section-8.4__;Iw!!NEt6yMaO-gk!X5JG5RvPO7zSCWr0y8h4SY2L5wTHUtXyL2Mv8qCzOC5-z59jAW73EAj9vdkbfS8H$> the endpoint of the SR Policy is matched with the BGP nexthop.

Thanks,
Ketan

From: Rajesh M <[e-mail]<mailto:[e-mail]>>
Sent: 01 July 2021 07:58
To: [e-mail]<mailto:[e-mail]>; Clarence Filsfils (cfilsfil) <[e-mail]<mailto:[e-mail]>>; Ketan Talaulikar (ketant) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi All,

As per the draft

"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<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-07*ref-I-D.ietf-spring-segment-routing-policy__;Iw!!NEt6yMaO-gk!X5JG5RvPO7zSCWr0y8h4SY2L5wTHUtXyL2Mv8qCzOC5-z59jAW73EAj9vTe1LjMn$>], then the

effective SR Policy is <S1, S2, S3-Service-SID>"



Here also "ingress PE SHOULD perform resolvability check for the S3 Service SID before considering the received prefix for the BGP best path computation"



Lets consider s3 service SID resolution over SRv6 TE Policy, destination address(or endpoint) of an SRv6 TE Policy is a 128 bit address(host address).So for each service SID we need to configure SRv6 TE Policy (SRV6 TE policy destination address as service SID) ?





Thanks

Rajesh















Juniper Business Use Only