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

Robert Raszuk <robert@raszuk.net> Thu, 22 July 2021 11:49 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 8A7853A436C for <spring@ietfa.amsl.com>; Thu, 22 Jul 2021 04:49:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 K3EfD4CnJuoF for <spring@ietfa.amsl.com>; Thu, 22 Jul 2021 04:49:18 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 C97A03A4367 for <spring@ietf.org>; Thu, 22 Jul 2021 04:49:17 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id g22so8140812lfu.0 for <spring@ietf.org>; Thu, 22 Jul 2021 04:49:17 -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=6FSZsGKDHX5ic4UZbYJmkFEpYl3yD683JbqY6xDYDaI=; b=Rf9hvRKbmiwvyKRNYFtUfXPxq8qnXF3emEW2WmIfIZcZ9SDh+F/ur6GHMjB5Ct7fu2 j+m1rXIIzaz0mjyra128ux3Im35g60nEJw7JuzKy7jhQK3f928tvUo2py49pUxqbvXs5 f728io99NUbjeA5eizBjeynZdBsCdjTqDdgnOpOy8gCjuu+/tkHYajDlrtU7goD39Jdz UanIEiaGYXuQmb1mRZovbmBZYKUkuXTZO/dMkBE/AV/5TGvhNJSPiAnNA3fmOYLozCo+ 4+Ff6RbrSVV5+JEjurLyWDqajjjIEXqTeqk57IeNfYi3rbR55zq/HASGch0inJ5eDwi5 8EYg==
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=6FSZsGKDHX5ic4UZbYJmkFEpYl3yD683JbqY6xDYDaI=; b=puZ566gA+oi1PgLazsWZI/g6RYCr4oby27KNH3BahZAkxNw+Q/DLB1yDej2GoYhwA1 5ydpddmUBs8mbFofHStcLMSdMi6wd5ZCQqo9qcD0KC44CLf9sStmjaJt6dRkywkwAVDk QzI3grRKylv846qW/xOaPagZPe+r6MGaNmX3hsRyNNjXG2GMQHxS9n4W5Ah5jhqzbPAY 39ICmzeAiEu+RNtpdvk3tLgUIDe9xF5WpBpmYXtjcoALKAV4z74peSTG3RgsS+LMzTLF 6XR0zSHTo8LBzFAENm5XK+a3ZHPTp364ofoT0TC1zvcUIbYMVb1SZim2R3pbBvmLi7hW eebw==
X-Gm-Message-State: AOAM531izjHe4W11gN3kbuCyEa0WUw2XmBjSK+Pfy7Hn+5E6YZgM07kf XDn27eiPK+s/O2pKLSXBN0cXqBT7Niwkde3UeHrIwg==
X-Google-Smtp-Source: ABdhPJzdWV+LDlKWlfQhYbNJgow1BUXxTUZrX6dCg3YJnbArP6sg12lov0vXoGSf+Gq3h0xr1erbwd+U/E1HggBFEN0=
X-Received: by 2002:a19:fc13:: with SMTP id a19mr30549693lfi.581.1626954554623; Thu, 22 Jul 2021 04:49:14 -0700 (PDT)
MIME-Version: 1.0
References: <D9D76C88-0466-4AB8-8D4E-CDE10D924B74@juniper.net> <MW3PR11MB4570A0EA852747EEA4CABEDFC1E49@MW3PR11MB4570.namprd11.prod.outlook.com> <2EDFEEA6-F3E6-42BB-B888-804B06101908@juniper.net> <MW3PR11MB4570454145E7F0A4B218AA17C1E49@MW3PR11MB4570.namprd11.prod.outlook.com>
In-Reply-To: <MW3PR11MB4570454145E7F0A4B218AA17C1E49@MW3PR11MB4570.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 22 Jul 2021 13:49:03 +0200
Message-ID: <CAOj+MMGYxVfKfg8BmF5q7PVY20pbdAzwCoy9ZUNjPyMWLf=uKw@mail.gmail.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Cc: Salih K A <salih@juniper.net>, Rajesh M <mrajesh@juniper.net>, "draft-ietf-bess-srv6-services@ietf.org" <draft-ietf-bess-srv6-services@ietf.org>, "spring@ietf.org" <spring@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004b668105c7b4e065"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/eXeB3hvaKTZ8gMcUBViWnuG4Ecs>
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: Thu, 22 Jul 2021 11:49:24 -0000

IMO we could add to the draft a statement that implementation MUST/SHOULD
support fallback to any available forwarding plane. But I am not sure if
this will not turn out against some implementations which may have problem
with that.

Order of such fallback is a policy/cfg decision.

Likewise before considering any forwarding plane use a data plane
reachability to the endpoint must be validated/tested - that should go
without saying but as we know there are implementations which only rely on
a control plane which is proven in action to be a rather poor method. There
are number of reasons where presence in RIB/inet does is not the same as
data plane reachability .

Thx,
Robert.



On Thu, Jul 22, 2021 at 12:41 PM Ketan Talaulikar (ketant) <ketant@cisco.com>
wrote:

> Hi Salih,
>
>
>
> The preference for steering over SR Policy applies to both SR-MPLS and
> SRv6. So we are covered from that perspective.
>
>
>
> I get the impression that this email discussion thread about “fallback” is
> about when sending over a non-SR Policy based steering mechanism. That too,
> I get the impression is that it is specifically about the scenario where
> there might not be a reachability via IGP FlexAlgo for the egress PE’s
> Locator from which the SRv6 service SID is allocated from.
>
>
>
> To me (and few other WG members), an alternate path or tunnel mechanism to
> reach the egress PE is something that is deployment specific and can be
> implemented via various mechanisms. While Shraddha has proposed a mechanism
> for this, I’ve also described a new other ways – there will be more. While
> the draft currently does not discuss this, it does not preclude any of
> these mechanisms either.
>
>
>
> The draft is currently done with WGLC and is in our AD (Martin’s) Q for
> his review. The question for the WG is if we do really need to clarify
> something about this “FlexAlgo fallback” case and if so, come up with some
> proposed text. IMHO details of such fallback mechanisms are outside the
> scope of this document and we can say so if that helps.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Salih K A <salih@juniper.net>
> *Sent:* 22 July 2021 15:35
> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>om>; Rajesh M <
> mrajesh@juniper.net>
> *Cc:* draft-ietf-bess-srv6-services@ietf.org; spring@ietf.org;
> bess@ietf.org
> *Subject:* Re: [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> Thanks, Ketan.
>
>
>
> This indicates a preference for steering over SR Policy while using color
> extended community.
>
> Then specify color only bits etc modes for specifying fallbacks if
> required. Currently it doesn’t talk about flex (but mention mostly IGP path
> to the next-hop N) and hence it need not necessarily pick SRv6 flex algo
> paths.
>
>
>
> Are we suggesting only if some indication comes the fallback will happen
> to flex algo? OR can we define an order like:
>
> SRv6 policy (using BGP NH)
>
> SRv6 Flex (using SRv6 Service SID)
>
>
>
> and a mention of local policy which can override if required.
>
>
>
> Regards,
>
> Salih
>
> *From: *"Ketan Talaulikar (ketant)" <ketant@cisco.com>
> *Date: *Thursday, July 22, 2021 at 2:25 PM
> *To: *Salih K A <salih@juniper.net>et>, Rajesh M <mrajesh@juniper.net>
> *Cc: *"draft-ietf-bess-srv6-services@ietf.org" <
> draft-ietf-bess-srv6-services@ietf.org>gt;, "spring@ietf.org" <
> spring@ietf.org>gt;, "bess@ietf.org" <bess@ietf.org>
> *Subject: *RE: [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Salih,
>
>
>
> Could you please check the following regarding the choice/fallback when
> using SR Policy based steering?
>
>
>
>
> 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!TYCZx62Jhc5xQg9DaeTZQM8PD_jYpavDX9bwo69wEp_Rycrt39LGrMOUxwCSPQ$>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13#section-8.8
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13*section-8.8__;Iw!!NEt6yMaO-gk!TYCZx62Jhc5xQg9DaeTZQM8PD_jYpavDX9bwo69wEp_Rycrt39LGrMMv4_vtIA$>
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Salih K A <salih@juniper.net>
> *Sent:* 22 July 2021 14:02
> *To:* Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org>rg>;
> Rajesh M <mrajesh@juniper.net>
> *Cc:* draft-ietf-bess-srv6-services@ietf.org; spring@ietf.org;
> bess@ietf.org
> *Subject:* Re: [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> Hi Ketan,
>
>
>
> 1 clarification query:
>
>
>
> With flex algo and SRTE policies, service routes can carry color extended
> communities.
>
> Now for the ingress, how to decide whether to resolve over SRv6 Service
> SID (to choose flex algo) OR over BGP Protocol next hop (to choose SRTE)?
>
> In a domain both can be present & operators may want fallbacks as well if
> one is not available. So, I think it’s better to clarify that to avoid
> ambiguity.
>
>
>
> Thanks,
> Salih
>
> *From: *spring <spring-bounces@ietf.org> on behalf of "Ketan Talaulikar
> (ketant)" <ketant=40cisco.com@dmarc.ietf.org>
> *Date: *Thursday, July 22, 2021 at 1:19 PM
> *To: *Rajesh M <mrajesh@juniper.net>
> *Cc: *"draft-ietf-bess-srv6-services@ietf.org" <
> draft-ietf-bess-srv6-services@ietf.org>gt;, "spring@ietf.org" <
> spring@ietf.org>gt;, "bess@ietf.org" <bess@ietf.org>
> *Subject: *Re: [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Resending with individual email addressed trimmed
>
>
>
> *From:* Ketan Talaulikar (ketant)
> *Sent:* 22 July 2021 13:13
> *To:* Rajesh M <mrajesh@juniper.net>et>; Rajesh M <
> mrajesh=40juniper.net@dmarc.ietf.org>gt;; Rabadan, Jorge (Nokia -
> US/Mountain View) <jorge.rabadan@nokia.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; Shraddha Hegde <shraddha@juniper.net>et>;
> bess@ietf.org; Srihari Sangli <ssangli@juniper.net>
> *Subject:* RE: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> Hi Rajesh,
>
>
>
> My apologies for the delay in my response. However, some of my co-authors
> and other WG members have already clarified this point. Let me try to
> summarize.
>
>
>
> The draft covers two SRv6 based mechanisms for the transport of services
> between SRv6 PEs. (1) using SR Policy based steering (i.e. for service
> routes with Color Extended Communities) using the H.encap construct along
> with a list of SRv6 segments  and the other (2) using H.encap with just the
> SRv6 Service SID in the IPv6 DA.
>
>
>
> As mentioned in the draft, it is required to verify the reachability of
> the SRv6 Service SID before the mechanism (2) can be used. This is an
> explicit clarification for verification of reachability. In an MPLS-VPN
> scenario, if the egress PE NH’s IP route is reachable at the ingress PE but
> without an MPLS label, such a path cannot be used. This is semantically
> similar.
>
>
>
> The mechanism (1) is different since the routing to the egress PE is via
> SR Policy and hence the requirement for verification of reachability of the
> SRv6 Service SID is not there.
>
>
>
> There is no mandate for the setting of the NH since that is left to
> deployment design.
>
>
>
> I hope this helps in addition to the various clarifications already
> provided by others.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Rajesh M <mrajesh@juniper.net>
> *Sent:* 22 July 2021 12:09
> *To:* Rajesh M <mrajesh=40juniper.net@dmarc.ietf.org>rg>; Rabadan, Jorge
> (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>om>; 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; Shraddha Hegde <shraddha@juniper.net>et>;
> bess@ietf.org; Srihari Sangli <ssangli@juniper.net>
> *Subject:* RE: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> Could Authors respond to this ?
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Rajesh M <mrajesh=40juniper.net@dmarc.ietf.org>
> *Sent:* Monday, July 19, 2021 7:28 PM
> *To:* Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>om>;
> Rajesh M <mrajesh@juniper.net>et>; 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; Shraddha Hegde <shraddha@juniper.net>et>;
> bess@ietf.org; Srihari Sangli <ssangli@juniper.net>
> *Subject:* RE: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> 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 - US/Mountain View) <jorge.rabadan@nokia.com>
>
> *Sent:* Monday, July 19, 2021 7:17 PM
> *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; Shraddha Hegde <shraddha@juniper.net>et>;
> bess@ietf.org; Srihari Sangli <ssangli@juniper.net>
> *Subject:* Re: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> 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
>