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

Gyan Mishra <hayabusagsm@gmail.com> Sat, 24 July 2021 06:56 UTC

Return-Path: <hayabusagsm@gmail.com>
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 DB2D33A2E56; Fri, 23 Jul 2021 23:56:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 zqg9R2ayXsdt; Fri, 23 Jul 2021 23:56:51 -0700 (PDT)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 A6D803A2E57; Fri, 23 Jul 2021 23:56:50 -0700 (PDT)
Received: by mail-pj1-x102d.google.com with SMTP id q17-20020a17090a2e11b02901757deaf2c8so6823269pjd.0; Fri, 23 Jul 2021 23:56:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CwkQWbKnpoKiQqSMJUysiBana8GhVxN3XEPYyPszcLk=; b=EuIzULTaZFwXGbB9U5wwT7s9W5opassWcLUI4hatx/KPVFHWqmmCvIr3vlenZBBIxU gMoYGW8sU5BOYxlrBofyUwJW13O+Qz81iKcx1Vgt4z8Fg+BqrDss1fGoVt4ddng68pp+ 0iuh33ClATQVWQB8L9JllGAGexmYjjO5WLJIY/0nr08pOOQ5zC46zrdwKR6DcYqBDqVy 5w1DvgJl4d2EHPPjQy6bImvFn3sX7kEWxj0HZaKqphU/N02qn2ZPdJiAma32NK9qdb6C AiggkHqOADeMuaZTDos3yRbjARxJwKD4zui3tPUDErPYwmAtDI27s6KB6ekoX5/HhrQu mT5Q==
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=CwkQWbKnpoKiQqSMJUysiBana8GhVxN3XEPYyPszcLk=; b=KIzmp3fNLd3ddUvo2xgndGOQ69PBd6hyP2FCQ3I5upo5WtkwoYew8TT2GImzmU2srr 2jcOw4NpKzznqrHO+Px3PXkzloJpH9zVPv9PGO8qyjN1VYHxdxjgS/air7UZpUQovRs+ q2GlHCXIIb27EMyYxWDvgKVkrBKymBu950FwvvxVFbp1B4zYWWBS04LGM/gnIv8EOvjR 3DcvYaWZBd3zTClMdbR+PQo3n2jGwDxVKBU16IbL50yMcbocvSUPxk6Nvt/n+kGoEEHO 4pjN9VcY+F/6zj9VqVj29h8I1Ft8qZk8QLRH3qBr1KPGrG+LkBj5w/U7WcgBHLgQmpda dMMw==
X-Gm-Message-State: AOAM531suJ2Xq4Gkv+/WQQwwKfKtf05KyET/H+SrskJoQXC7Peo5U26D URNOEKBn8Je9f3oeP9DeINC5a7V2FeGTe4ZUg5w=
X-Google-Smtp-Source: ABdhPJyB0YNBUmnRK7Sp1iMrsJO/KR2aLHashOrmSy1rV58DXuYeoPFnOd6z1aw4BkDvNQKvXL+MExRA7Vf/EN9J2L4=
X-Received: by 2002:a05:6a00:214a:b029:323:3c6e:a24a with SMTP id o10-20020a056a00214ab02903233c6ea24amr7767287pfk.4.1627109808888; Fri, 23 Jul 2021 23:56:48 -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> <BN6PR05MB363439BAFB0BD66C0DC53354BEE19@BN6PR05MB3634.namprd05.prod.outlook.com> <BN6PR05MB3634E1880604AC6AC11ECAD8BEE49@BN6PR05MB3634.namprd05.prod.outlook.com> <MW3PR11MB4570AFB28290F5AA0C871141C1E49@MW3PR11MB4570.namprd11.prod.outlook.com> <DM6PR08MB602757AF0FDA0B510B89923DE4E59@DM6PR08MB6027.namprd08.prod.outlook.com> <MW3PR11MB4570C5B83B5DA1022AED682FC1E59@MW3PR11MB4570.namprd11.prod.outlook.com> <DM6PR08MB60274C149331AD9D08C0ED39E4E59@DM6PR08MB6027.namprd08.prod.outlook.com>
In-Reply-To: <DM6PR08MB60274C149331AD9D08C0ED39E4E59@DM6PR08MB6027.namprd08.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sat, 24 Jul 2021 02:56:37 -0400
Message-ID: <CABNhwV2sfTSo4_9h-OVOUTa8W0By_swwhMsOUSnzymndMafWbA@mail.gmail.com>
To: "Aissaoui, Mustapha (Nokia - CA/Ottawa)" <mustapha.aissaoui@nokia.com>
Cc: "Ketan Talaulikar (ketant)" <ketant@cisco.com>, Shraddha Hegde <shraddha@juniper.net>, "bess@ietf.org" <bess@ietf.org>, "draft-ietf-bess-srv6-services@ietf.org" <draft-ietf-bess-srv6-services@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002b603305c7d9063a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/g8ZawXs_6FDTkKLTRfFXHWWwkTQ>
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: Sat, 24 Jul 2021 06:56:56 -0000

Hi Shraddha

I agree the fallback mechanisms are important to operators but as there are
many complex scenarios related to fallback and some of which include SRv6
to SR-MPLS interworking, I agree that this is important and as such can be
captured in a separate document that defines all the permutations in detail.

As this SRv6 BGP overlay services specification is critical for operators
as it’s in WGLC I think it should proceed to publication.

Kind Regards

Gyan

On Fri, Jul 23, 2021 at 12:40 PM Aissaoui, Mustapha (Nokia - CA/Ottawa) <
mustapha.aissaoui@nokia.com> wrote:

> That is great. Thank you.
>
>
>
> Mustapha.
>
>
>
> *From:* Ketan Talaulikar (ketant) <ketant@cisco.com>
> *Sent:* Friday, July 23, 2021 11:08 AM
> *To:* Aissaoui, Mustapha (Nokia - CA/Ottawa) <mustapha.aissaoui@nokia.com>
> *Cc:* spring@ietf.org; Shraddha Hegde <shraddha@juniper.net>;
> bess@ietf.org; draft-ietf-bess-srv6-services@ietf.org
> *Subject:* RE: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> < trimming list to mostly mailers >
>
>
>
> Hi Mustapha,
>
>
>
> I agree.
>
>
>
> Also after seeing Shraddha’s latest email, the coverage and details for
> the fallback mechanisms that she seems to be looking for is quite vast and
> better tackled in a separate document since this one has completed its
> WGLC. Some of those concepts are applicable for MPLS as well and not SRv6
> specific.
>
>
>
> We (authors) will work on some text proposal and get back to the WG next
> week.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Aissaoui, Mustapha (Nokia - CA/Ottawa) <
> mustapha.aissaoui@nokia.com>
> *Sent:* 23 July 2021 19:20
> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>; Rajesh M <
> mrajesh@juniper.net>; Rajesh M <mrajesh@juniper.net>; Rabadan, Jorge
> (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>;
> gdawra.ietf@gmail.com; Clarence Filsfils (cfilsfil) <cfilsfil@cisco.com>;
> robert@raszuk.net; bruno.decraene@orange.com
> *Cc:* spring@ietf.org; bgp@ans.net; Srihari Sangli <ssangli@juniper.net>;
> Shraddha Hegde <shraddha@juniper.net>; bess@ietf.org
> *Subject:* RE: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> Hi Ketan,
>
> I believe it will be worth expanding the text in
> draft-ietf-bess-srv6-services to describe the two types of transport more
> consistently and along the lines of what you wrote below. Also, I would
> propose that we move away from terminology like best-effort service and
> instead just mention shortest path forwarding in base topology or in
> flex-algo topology.
>
>
>
> Mustapha.
>
>
>
> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Ketan Talaulikar
> (ketant)
> *Sent:* Thursday, July 22, 2021 3:43 AM
> *To:* Rajesh M <mrajesh@juniper.net>; Rajesh M <
> mrajesh=40juniper.net@dmarc.ietf.org>; Rabadan, Jorge (Nokia -
> US/Mountain View) <jorge.rabadan@nokia.com>; gdawra.ietf@gmail.com;
> Clarence Filsfils (cfilsfil) <cfilsfil@cisco.com>; robert@raszuk.net;
> bruno.decraene@orange.com
> *Cc:* spring@ietf.org; bgp@ans.net; Srihari Sangli <ssangli@juniper.net>;
> Shraddha Hegde <shraddha@juniper.net>; bess@ietf.org
> *Subject:* Re: [spring] 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>; Rabadan, Jorge
> (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>; Ketan Talaulikar
> (ketant) <ketant@cisco.com>; gdawra.ietf@gmail.com; Clarence Filsfils
> (cfilsfil) <cfilsfil@cisco.com>; robert@raszuk.net;
> bruno.decraene@orange.com
> *Cc:* spring@ietf.org; bgp@ans.net; Shraddha Hegde <shraddha@juniper.net>;
> 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>;
> Rajesh M <mrajesh@juniper.net>; Ketan Talaulikar (ketant) <
> ketant@cisco.com>; gdawra.ietf@gmail.com; Clarence Filsfils (cfilsfil) <
> cfilsfil@cisco.com>; robert@raszuk.net; bruno.decraene@orange.com
> *Cc:* spring@ietf.org; bgp@ans.net; Shraddha Hegde <shraddha@juniper.net>;
> 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>; Rajesh M <
> mrajesh=40juniper.net@dmarc.ietf.org>; Ketan Talaulikar (ketant) <
> ketant@cisco.com>; gdawra.ietf@gmail.com; Clarence Filsfils (cfilsfil) <
> cfilsfil@cisco.com>; robert@raszuk.net; bruno.decraene@orange.com
> *Cc:* spring@ietf.org; bgp@ans.net; Shraddha Hegde <shraddha@juniper.net>;
> 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>, Ketan Talaulikar
> (ketant) <ketant@cisco.com>, gdawra.ietf@gmail.com <gdawra.ietf@gmail.com>,
> Clarence Filsfils (cfilsfil) <cfilsfil@cisco.com>, robert@raszuk.net <
> robert@raszuk.net>, bruno.decraene@orange.com <bruno.decraene@orange.com>,
> Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>
> *Cc: *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>
> *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>; gdawra.ietf@gmail.com;
> Clarence Filsfils (cfilsfil) <cfilsfil@cisco.com>; robert@raszuk.net;
> bruno.decraene@orange.com; jorge.rabadan@nokia.com
> *Cc:* spring@ietf.org; bgp@ans.net; Shraddha Hegde <shraddha@juniper.net>;
> 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
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*