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*
- [spring] SRv6 BGP based Overlay Services (draft-i… Rajesh M
- Re: [spring] SRv6 BGP based Overlay Services (dra… Rajesh M
- Re: [spring] SRv6 BGP based Overlay Services (dra… Rabadan, Jorge (Nokia - US/Mountain View)
- Re: [spring] SRv6 BGP based Overlay Services (dra… Robert Raszuk
- Re: [spring] SRv6 BGP based Overlay Services (dra… Rajesh M
- Re: [spring] SRv6 BGP based Overlay Services (dra… Gaurav Dawra
- Re: [spring] SRv6 BGP based Overlay Services (dra… Aissaoui, Mustapha (Nokia - CA/Ottawa)
- Re: [spring] SRv6 BGP based Overlay Services (dra… Shraddha Hegde
- Re: [spring] SRv6 BGP based Overlay Services (dra… Robert Raszuk
- Re: [spring] SRv6 BGP based Overlay Services (dra… Shraddha Hegde
- Re: [spring] SRv6 BGP based Overlay Services (dra… Robert Raszuk
- Re: [spring] SRv6 BGP based Overlay Services (dra… Shraddha Hegde
- Re: [spring] SRv6 BGP based Overlay Services (dra… UTTARO, JAMES
- Re: [spring] SRv6 BGP based Overlay Services (dra… Robert Raszuk
- Re: [spring] SRv6 BGP based Overlay Services (dra… Aissaoui, Mustapha (Nokia - CA/Ottawa)
- Re: [spring] SRv6 BGP based Overlay Services (dra… Srihari Sangli
- Re: [spring] SRv6 BGP based Overlay Services (dra… Aissaoui, Mustapha (Nokia - CA/Ottawa)
- Re: [spring] SRv6 BGP based Overlay Services (dra… UTTARO, JAMES
- Re: [spring] SRv6 BGP based Overlay Services (dra… Shraddha Hegde
- Re: [spring] SRv6 BGP based Overlay Services (dra… Aissaoui, Mustapha (Nokia - CA/Ottawa)
- Re: [spring] SRv6 BGP based Overlay Services (dra… Rajesh M
- Re: [spring] SRv6 BGP based Overlay Services (dra… Ketan Talaulikar (ketant)
- Re: [spring] SRv6 BGP based Overlay Services (dra… Ketan Talaulikar (ketant)
- Re: [spring] SRv6 BGP based Overlay Services (dra… Ketan Talaulikar (ketant)
- Re: [spring] SRv6 BGP based Overlay Services (dra… Salih K A
- Re: [spring] SRv6 BGP based Overlay Services (dra… Ketan Talaulikar (ketant)
- Re: [spring] SRv6 BGP based Overlay Services (dra… Rajesh M
- Re: [spring] SRv6 BGP based Overlay Services (dra… Ketan Talaulikar (ketant)
- Re: [spring] SRv6 BGP based Overlay Services (dra… Salih K A
- Re: [spring] SRv6 BGP based Overlay Services (dra… Ketan Talaulikar (ketant)
- Re: [spring] SRv6 BGP based Overlay Services (dra… Robert Raszuk
- Re: [spring] SRv6 BGP based Overlay Services (dra… Shraddha Hegde
- Re: [spring] SRv6 BGP based Overlay Services (dra… Rajesh M
- Re: [spring] SRv6 BGP based Overlay Services (dra… Aissaoui, Mustapha (Nokia - CA/Ottawa)
- Re: [spring] SRv6 BGP based Overlay Services (dra… Ketan Talaulikar (ketant)
- Re: [spring] SRv6 BGP based Overlay Services (dra… Aissaoui, Mustapha (Nokia - CA/Ottawa)
- Re: [spring] SRv6 BGP based Overlay Services (dra… Gyan Mishra
- Re: [spring] SRv6 BGP based Overlay Services (dra… Ketan Talaulikar (ketant)
- Re: [spring] SRv6 BGP based Overlay Services (dra… Wanghaibo (Rainsword)
- Re: [spring] SRv6 BGP based Overlay Services (dra… Ketan Talaulikar (ketant)
- Re: [spring] SRv6 BGP based Overlay Services (dra… Wanghaibo (Rainsword)
- Re: [spring] SRv6 BGP based Overlay Services (dra… Ketan Talaulikar (ketant)