Rajesh,
Also you can change the service SID for a subset of prefixes using a policy, to
apply a flex-algo for example, but you do not want to change the next-hop for
each new service SID.
Mustapha.
From: spring On Behalf Of Rabadan, Jorge (Nokia -
US/Mountain View)
Sent: Monday, July 19,
+1 on Jorge and Robert. I don’t think we should mandate.
Gaurav
> On Jul 19, 2021, at 6:52 AM, Robert Raszuk wrote:
>
>
> I agree with Jorge..
>
> In fact I find the tone of the comment to be very inappropriate:
>
> > In case of best effort/flex algo we must mandate user to set
Hi All,
For best effort service, flex algo - Resolve SRv6 Service SID for forwarding.
For SR-TE, CAR/CT - Resolve BGP next hop for forwarding.
There is no unification here, it's better to unify.
Any other solution is OK.
Thanks
Rajesh
Juniper Business Use Only
From: Rabadan, Jorge (Nokia -
I agree with Jorge..
In fact I find the tone of the comment to be very inappropriate:
*> In case of best effort/flex algo we must mandate user to set
corresponding locator as BGP nexthop for srv6 routes.*
*No we MUST not mandate anything to the user. *
*We MUST provide flexibility to address
Hi Rajesh,
The draft is written so that the next-hop address MAY be covered by the
locator, but there are cases in which the next-hop address is not part of the
locator prefix, and there are implementations already allowing that, so I don’t
agree the document should mandate what you are
Hi Authors,
Please respond.
Thanks
Rajesh
Juniper Business Use Only
From: spring On Behalf Of Rajesh M
Sent: Thursday, July 15, 2021 4:36 PM
To: Ketan Talaulikar (ketant) ; gdawra.i...@gmail.com;
Clarence Filsfils (cfilsfil) ; rob...@raszuk.net;
bruno.decra...@orange.com;
Hi All,
As per this draft, this is how resolution must work.
1)For Non Intent service Route:
if BGP next hop is not reachable return.
Resolve SRv6 Service SID for forwarding.
2)For Intent service Route (IGP Flex-Algo first then BGP CAR then SR Policy):
BGP next hop is not reachable return.
The implementation of Link Bandwidth in FRR uses a transitive community to
signal & perform an automatic accumulation at the AS boundary. This seems
useful as it obviates the need for additional info (configuration) at each AS
boundary to generate a new community using accumulated values.
Hi Authors,
Please respond.
Thanks
Rajesh
Juniper Business Use Only
From: Rajesh M
Sent: Thursday, July 8, 2021 2:24 PM
To: Rajesh M ; dh...@cisco.com; swaag...@cisco.com;
cfils...@cisco.com; ket...@cisco.com
Cc: spr...@ietf.org; bess@ietf.org
Subject: RE: draft-dskc-bess-bgp-car-02
