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

Robert Raszuk <robert@raszuk.net> Mon, 19 July 2021 13:52 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 C662C3A3465 for <spring@ietfa.amsl.com>; Mon, 19 Jul 2021 06:52:54 -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 LmSi-AYJnaok for <spring@ietfa.amsl.com>; Mon, 19 Jul 2021 06:52:49 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 E5C083A3467 for <spring@ietf.org>; Mon, 19 Jul 2021 06:52:48 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id b29so5361491ljf.11 for <spring@ietf.org>; Mon, 19 Jul 2021 06:52:48 -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=aSwXjo1kb8Yn6Lvn8GWcBHfckVd+Jy3uVb8iwNH2jjk=; b=AXr3mQptGDcKIjLzG0EhNzxgkDQn5C3J7wYmwTTQW4mYI+qmcPxcrx1Lpqg5Fk/n94 fkgtL6qZNm+2NPkYtYnul2VrfW4YXZ52ylmGcYoD6sHGbunG2NuZ2V6U5ShVL+5ML40q yM15gZ7dXfTnixmyaPTldgaKaX7+QzlZSz2bcP/7uVqxNf4ZQDJJQgzjKnsWB81lDOCv XHZ0Xnba1T7unthFjEcVoZnP890nD+CvDM1ANDbqI+Ojm1BFEmCP0/gxOVwe8iekm3r9 5SY4PvD4crZsqPqiV7l/bxWZlZ0CzleJhgUH7Z5anSoA60O14dZ+A9UvYTErBrkQPw4f +iXQ==
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=aSwXjo1kb8Yn6Lvn8GWcBHfckVd+Jy3uVb8iwNH2jjk=; b=sEdLKznBJdcrscermtIeTHqf0x+7VP8ya8uPmaEdVrAlmFcR77pFj9vfbdpSVOtBsm jDrgrZaxvjgvtRmaYXwka/r4ilnm40J/734rWfsW/ApuscbsSUTldNtUxwd+co8tzm5V RqpVHz3R0xmXSk/lxAVheMa4//frOnUDnJLdonAXefdP/lyV4jirSTfxPoEhBeXTv8cE n6QhLtLNNaIEJv8+oON1XneRzBshtEL7ytMHMmPREdl0lRUr/csebQaHS1C+6Nt9L5XL ZNFBledPzteTZRJuImn6mN6CgBaWm6VGiEmOZy48XGZ87Pn/Ixvz8x+cuJGidTEHYL8O BbTw==
X-Gm-Message-State: AOAM531nJlKmOhSc+TvX1gzEgyXSVf+HIULAGa3Z1uhu7vWxwJ1Rq/tR BuE+T9DRgG6Lob3x8mlVf06cuafB0Whaw4Sdx5Oujg==
X-Google-Smtp-Source: ABdhPJy3AtZbQdOjtDBN6ITporkouOm4/gAXeBY2zjUbqj1mruCZMJ+RygEm+FSaeda9KvS7lj1Ie0aQDU2i54NcNmw=
X-Received: by 2002:a2e:890f:: with SMTP id d15mr22438772lji.37.1626702761768; Mon, 19 Jul 2021 06:52:41 -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>
In-Reply-To: <BY3PR08MB70603EB604AF65D3580E3794F7E19@BY3PR08MB7060.namprd08.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 19 Jul 2021 15:52:31 +0200
Message-ID: <CAOj+MMH6KVNBzJt488tSHRAo-dSNcO5OeATyhzj3sPCKc8=BEg@mail.gmail.com>
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
Cc: 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>, Shraddha Hegde <shraddha@juniper.net>, "bess@ietf.org" <bess@ietf.org>, Srihari Sangli <ssangli@juniper.net>
Content-Type: multipart/alternative; boundary="000000000000454a0805c77a402d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/wy021EUcQjuKYahn7kt6YdjGVVA>
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: Mon, 19 Jul 2021 13:52:55 -0000

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 all deployment cases user may
have. *

*Best,*
*R.*



On Mon, Jul 19, 2021 at 3:47 PM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.rabadan@nokia.com> wrote:

> 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
>