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

Robert Raszuk <robert@raszuk.net> Tue, 20 July 2021 05:46 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609653A125E for <spring@ietfa.amsl.com>; Mon, 19 Jul 2021 22:46:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjYwXBEcyVov for <spring@ietfa.amsl.com>; Mon, 19 Jul 2021 22:46:52 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D343A1256 for <spring@ietf.org>; Mon, 19 Jul 2021 22:46:52 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id i5so34074979lfe.2 for <spring@ietf.org>; Mon, 19 Jul 2021 22:46:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dJGopMMKFR5mfoCibKj1u7kOSRYVkqNMzCtBuFcUZIo=; b=O4FGJyHhhiodp9pSgCFE3a9hVt6ScuOzee4igYpLBoMgPFOKw0I8LPumhPPFMEat8S fKi/+GRRjXRG/Z9QliLLjHIMe2LmilB9R6zY48fpLoeDjBrGD2UVkFx7a0f7GMG/tm/J sPVfsMitXC2MdaFpt3nqGYURio+19k19+XJsNRj5iipMKEL1t00ANy3+LoAmsRPAORw1 0ZDE63AJvmxZB0sTDpRs7LYFNY1Jib6LZV7oiI2cYK3nEzuvkV9znvhZXQcfhJn1PpzA QZjBdvQPwljcwWiBep37EJ5uY+/iLG55rTSqAjGTASsp3kd+eg44kUwFPaO5a9U2u68B f7Qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dJGopMMKFR5mfoCibKj1u7kOSRYVkqNMzCtBuFcUZIo=; b=fqDTL4NDgV/4lF727DO8v+LO8tyz8vjaSDM+txjWaYbfQAtAGvyx5DPP4/IMbJfQeY 4tZb34VGpAgAZtC+vdIuHQP02OcwBZsCjCgt42liRfCdMnaxCseQY1Pq25EQcQQt0F7K 8tp7Ok3olM2KPOuniupK5nyRUoPaC543JZZ4bhnEbpi1LyLCXbw8LlLoTZPHRXaF9pet us9ZToVN1HY2drLC6MBvMclGtLtSHTzsjvB2vziyfxEvx0yKK7D7nuIh98/OZMrOTCVm F0bgkNnWzjchmnb/11jdrqSC7EDZxtCJd2FssYAUrmZDdmTw/1PnaWZWrcqvCNi+5Ora JSDA==
X-Gm-Message-State: AOAM531JYraAKKi+EA+JT2hq2XJgFU0IYuKi8mmjiV34lVaJaJHlFX2Y QkwxF7iQ2JJ/1IpuS84Jw+/+j9zzVCiadrzh7/gpgQ==
X-Google-Smtp-Source: ABdhPJyhFxnZSFKsPV58ZselGFcoXejJ4JnaKDruAKRxJg65TdjHJOmonUWvTJ93J4nBionf2h/2PqrL8hkFGsJgyhQ=
X-Received: by 2002:a05:6512:400b:: with SMTP id br11mr20679356lfb.36.1626760004952; Mon, 19 Jul 2021 22:46:44 -0700 (PDT)
MIME-Version: 1.0
References: <BN6PR05MB36346DDD4F6824CD65D70491BE129@BN6PR05MB3634.namprd05.prod.outlook.com> <BN6PR05MB36341943DEC7D8DC5869A9E0BEE19@BN6PR05MB3634.namprd05.prod.outlook.com> <BY3PR08MB70603EB604AF65D3580E3794F7E19@BY3PR08MB7060.namprd08.prod.outlook.com> <DM6PR08MB6027C9A41B6B1DF2BB59687FE4E19@DM6PR08MB6027.namprd08.prod.outlook.com> <CY4PR05MB3576D4484BD96F6E08604AF4D5E29@CY4PR05MB3576.namprd05.prod.outlook.com>
In-Reply-To: <CY4PR05MB3576D4484BD96F6E08604AF4D5E29@CY4PR05MB3576.namprd05.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 20 Jul 2021 07:46:43 +0200
Message-ID: <CAOj+MMGuMG8jwEUbeUkZJc_vv+1y1cnav5rp1tL6drRr-G3sCA@mail.gmail.com>
To: Shraddha Hegde <shraddha@juniper.net>
Cc: "Aissaoui, Mustapha (Nokia - CA/Ottawa)" <mustapha.aissaoui@nokia.com>, "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>, Rajesh M <mrajesh@juniper.net>, Rajesh M <mrajesh=40juniper.net@dmarc.ietf.org>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>, "gdawra.ietf@gmail.com" <gdawra.ietf@gmail.com>, "Clarence Filsfils (cfilsfil)" <cfilsfil@cisco.com>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "spring@ietf.org" <spring@ietf.org>, "bgp@ans.net" <bgp@ans.net>, Srihari Sangli <ssangli@juniper.net>, "bess@ietf.org" <bess@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003af89005c7879480"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/UZQs4phzbTRrAsfxgW4EVrFCKJw>
Subject: Re: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Jul 2021 05:46:59 -0000

Shraddha,

In an SR network fallback to best effort will also result in encapsulated
forwarding using SR. It may not be as optimal service wise as using
flex-algo, but this is form of tunneling. Hence I don't think your comment
applies.

Note that operator may also choose to use IP tunneling for best effort
forwarding if SR best effort forwarding is not supported or enabled.

Best,
R.




On Tue, Jul 20, 2021 at 7:20 AM Shraddha Hegde <shraddha@juniper.net> wrote:

> Hi Authors,
>
>
>
> There is a possibility of a usecase that wants to use flex-algo paths if
> available and if flex-algo paths
>
> Are not available use best effort paths.
>
>
>
> “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 current text says for best effort tunnels Srv6 service SID resolution
> SHOULD be checked and
>
> I am told that (from previous mailing list exchanges) authors intend to
> update the text to make it applicable for flex-algo connectivity  as well.
>
>
>
> It is not possible to support fallback on best effort tunnels if flex-algo
> SRv6 service SIDs have to be resolved.
>
> It is possible to support fallback to best effort in SRv6 if packets can
> be tunneled to egress PE  (destination address being PE’s best effort END
> SID and service SID in the SRH)and
>
> then do a service SID lookup on egress, in which case there is no need to
> resolve the SRv6 service SIDs on the ingress.
>
>
>
> It is not clear whether the authors intend to support these kind of
> tunnelling to egress cases for
>
> Best effort and flex-algo transport. If it not going to be supported, pls
> add text indicating clearly
>
> Tunnelling is not required to be supported and hence Fallback to best
> effort  is also not supported.
>
>
>
> If that is not the intention, Its reasonable to update the text to
> indicate SRv6 service SIDs need not be resolved
>
> If the ingress is tunneling the packet.
>
>
>
> Rgds
>
> Shraddha
>
>
>
> Juniper Business Use Only
>
> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Aissaoui,
> Mustapha (Nokia - CA/Ottawa)
> *Sent:* Monday, July 19, 2021 7:34 PM
> *To:* Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>om>;
> Rajesh M <mrajesh@juniper.net>et>; Rajesh M <mrajesh=
> 40juniper.net@dmarc.ietf.org>gt;; Ketan Talaulikar (ketant) <ketant@cisco.com>om>;
> gdawra.ietf@gmail.com; Clarence Filsfils (cfilsfil) <cfilsfil@cisco.com>om>;
> robert@raszuk.net; bruno.decraene@orange.com
> *Cc:* spring@ietf.org; bgp@ans.net; Srihari Sangli <ssangli@juniper.net>et>;
> bess@ietf.org; Shraddha Hegde <shraddha@juniper.net>
> *Subject:* Re: [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> 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 <spring-bounces@ietf.org> *On Behalf Of *Rabadan, Jorge
> (Nokia - US/Mountain View)
> *Sent:* Monday, July 19, 2021 9:47 AM
> *To:* Rajesh M <mrajesh@juniper.net>et>; Rajesh M <
> mrajesh=40juniper.net@dmarc.ietf.org>gt;; Ketan Talaulikar (ketant) <
> ketant@cisco.com>gt;; gdawra.ietf@gmail.com; Clarence Filsfils (cfilsfil) <
> cfilsfil@cisco.com>gt;; robert@raszuk.net; bruno.decraene@orange.com
> *Cc:* spring@ietf.org; bgp@ans.net; Srihari Sangli <ssangli@juniper.net>et>;
> Shraddha Hegde <shraddha@juniper.net>et>; bess@ietf.org
> *Subject:* Re: [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> 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 suggesting.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *Rajesh M <mrajesh@juniper.net>
> *Date: *Monday, July 19, 2021 at 3:24 PM
> *To: *Rajesh M <mrajesh=40juniper.net@dmarc.ietf.org>rg>, Ketan Talaulikar
> (ketant) <ketant@cisco.com>om>, gdawra.ietf@gmail.com <gdawra.ietf@gmail.com>om>,
> Clarence Filsfils (cfilsfil) <cfilsfil@cisco.com>om>, robert@raszuk.net <
> robert@raszuk.net>gt;, bruno.decraene@orange.com <bruno.decraene@orange.com>om>,
> Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>
> *Cc: *spring@ietf.org <spring@ietf.org>rg>, bgp@ans.net <bgp@ans.net>et>,
> Shraddha Hegde <shraddha@juniper.net>et>, bess@ietf.org <bess@ietf.org>rg>,
> Srihari Sangli <ssangli@juniper.net>
> *Subject: *RE: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
> Hi Authors,
>
>
>
> Please respond.
>
>
>
> Thanks
>
> Rajesh
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Rajesh M
> *Sent:* Thursday, July 15, 2021 4:36 PM
> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>om>; gdawra.ietf@gmail.com;
> Clarence Filsfils (cfilsfil) <cfilsfil@cisco.com>om>; robert@raszuk.net;
> bruno.decraene@orange.com; jorge.rabadan@nokia.com
> *Cc:* spring@ietf.org; bgp@ans.net; Shraddha Hegde <shraddha@juniper.net>et>;
> bess@ietf.org
> *Subject:* [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> 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.
>
> Resolve SRv6 Service SID for forwarding(To find IGP flex algo).if
> successfully resolves then return.
>
> Resolve BGP next hop for forwarding (in case above is not success).
>
>
>
>
>
> *Using Service SID (overlay),for resolution is definitely not recommended.*
>
>
>
> *Instead in case of srv6, we always resolve on BGP nexthop. This will be
> in line with BGP legacy.*
>
> *In case of best effort/flex algo we must mandate user to set
> corresponding locator as BGP nexthop for srv6 routes.*
>
> *I think this is a reasonable mandate.*
>
>
>
> Thanks
>
> Rajesh
>
>
>
> Juniper Business Use Only
>