Re: [Idr] [spring] Comments: Route Origin Community in SR Policy(draft-ietf-spring-segment-routing-policy)

Gyan Mishra <hayabusagsm@gmail.com> Thu, 21 May 2020 19:17 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA033A0ABD; Thu, 21 May 2020 12:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 Ze1CqaLuOhDv; Thu, 21 May 2020 12:17:56 -0700 (PDT)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 F282E3A0A93; Thu, 21 May 2020 12:17:55 -0700 (PDT)
Received: by mail-io1-xd32.google.com with SMTP id o5so8727811iow.8; Thu, 21 May 2020 12:17:55 -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=WgMyHKtGo+Yw0/kfJCapgkRxpBSHymBX+8Gj+cSwL4w=; b=BstT/MqlOuqfCYscFZd9gGuXWJUXujiNQ2bjOUOlq2X3kIiXfYbO6z4huwbVDmyaeS yegy1NLzzvoEm4rT9j+E0QK/77qwxPZaRotOCpsbQmNaGqS2ne52lzGzfypY0H+slcPY Rca6OTZa/NlGY+qqzL6FvCsrDyg0e8kp7rimQSBCYVnYyu+HqkT1cRgMQnURq50TU+qk VqvwfNa3r+/eNGiRCxsuRjOrrgZBziXFkB5T67qVZ21w8yFyzNvebqi0Tc9DDXCjlKt7 skV2QyKLjZmunsLyY8E7X+8ndj6/mKruNd2pSQFk0dZaliToszIsFMcZX8P3YyCzKT/v xmTA==
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=WgMyHKtGo+Yw0/kfJCapgkRxpBSHymBX+8Gj+cSwL4w=; b=nJAmOl/0x8Wg4811gNvU/sIBgxHMWOSnJ1wRRO0O2V2/XRkDSqVbUN3Nj7O9wMnjzv EhPh1Lr1yy6dk/+w7TnDR+DRXYBEmo7BiD3+Vjx43e7ZLQoDPdQJzlNFinqU/CHffsYl +TPv5YRNJ44pDJxsmm6MLlpxg4juJZJs/rm812LpcJDsvtm+a3bbF7CR5O4lNJqZxgb2 giNuc8wkqFx0FWbfyLz8mU/Gi4OqsJNRB1Rgj+b7A9dUZzzd3V4+gAqPwXr2unk5arYH l0+5mNo29FRbMoP+rAtClBChQgCqefqROgg3alrXnbPl95kQMBcDQ3SGezXdx1qCXjns AkCw==
X-Gm-Message-State: AOAM530CedjX4UL5Z3emof/Aeu7H0Iasnprjjbbu9BYwwR0FduA/aOyG hy5qeN/XQymrZ6Y1tqg+IjjZPvPjYlal9yMi17Q=
X-Google-Smtp-Source: ABdhPJwbxye88U5syvN1V4fBSIlNY521KwsjWrBMgsSYH5PSPPsMPCBKXRB03ntGBBUgWndD/j8VBQWFUtcJpRm+0xk=
X-Received: by 2002:a6b:fc0d:: with SMTP id r13mr120009ioh.40.1590088674310; Thu, 21 May 2020 12:17:54 -0700 (PDT)
MIME-Version: 1.0
References: <C7C2E1C43D652C4E9E49FE7517C236CB029FAC88@dggeml529-mbx.china.huawei.com> <MW3PR11MB45702B49025A293583346F36C1AA0@MW3PR11MB4570.namprd11.prod.outlook.com> <CAOj+MMGbjvgn6VL3dKviuxzNNRk0pwFkBOTJUz15D8iSM9=-Rw@mail.gmail.com> <MW3PR11MB457083E56B77688CA68A2500C1B80@MW3PR11MB4570.namprd11.prod.outlook.com> <83bae48cc52d4a5da9a7ee76529a8d20@huawei.com> <CAOj+MMFs2fGy0ciyBJvoWng++oepamF8YxyO=QtR9yYWbazbqg@mail.gmail.com>
In-Reply-To: <CAOj+MMFs2fGy0ciyBJvoWng++oepamF8YxyO=QtR9yYWbazbqg@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Thu, 21 May 2020 15:17:42 -0400
Message-ID: <CABNhwV24xJ5jTfA2vzxS1ig8Wp2NbO1wiNeTJBc2Jd_yECE=xA@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: "Chengli (Cheng Li)" <c.l@huawei.com>, Fangsheng <fangsheng@huawei.com>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>, SPRING WG <spring@ietf.org>, Yangang <yangang@huawei.com>, "draft-ietf-spring-segment-routing-policy@ietf.org" <draft-ietf-spring-segment-routing-policy@ietf.org>, idr wg <idr@ietf.org>, stefano previdi <stefano@previdi.net>
Content-Type: multipart/related; boundary="0000000000009907d405a62d5ef4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Hd3xqHAN1G8-0FO0UE-ZklbmXiY>
Subject: Re: [Idr] [spring] Comments: Route Origin Community in SR Policy(draft-ietf-spring-segment-routing-policy)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 May 2020 19:18:00 -0000

On Wed, May 20, 2020 at 8:59 AM Robert Raszuk <robert@raszuk.net> wrote:

> Hi,
>
> > the node-address is generated by CSG1
>
> I don't think CSG1 needs to "generate" anything. Peers which send you
> particular policy are well known at CSG1.
>
> > The process described above will result in a waste of redundant
> candidate paths on CSG1,
>
> Well what you call "waste" I call redundancy. Sure keeping extra paths
> requires some cost, but building redundancy in control plane pays off.
>

    Gyan> I agree with Robert that the additional candidate path sent by
the RR could be used for redundancy.   However, I think the context of  SR
TE is that each candidate path is a single path option not multiple as the
redundancy is provided by different candidate paths.  That is the issue I
am guessing.


> Thx,
> R.
>
>
>
>
> On Wed, May 20, 2020 at 2:32 PM Fangsheng <fangsheng@huawei.com> wrote:
>
>> Hi Robert,
>>
>> Take the following picture as an example, I think you can understand our
>> problem more easily.
>>
>> The controller needs to notify the headend CSG1 through BGP SR Policy to
>> create a candidate path of SR Policy. This BGP SR Policy route will be
>> advertised to CSG1 through RR1 and RR2.
>>
>> According to the definition in draft, the key of a candidate path is
>> <Protocol-Origin, originator, discriminator>, where originator = <ASN,
>> node-address>, so a complete candidate path key is <Protocol-Origin, ASN,
>> node-address , discriminator>.
>>
>> However, in this specific example, the node-address is generated by CSG1,
>> and because CSG1 receives BGP SR Policy routes from RR1 and RR2,
>> respectively, CSG1 will get two different node-addresses. CSG1 thinks that
>> it is necessary to create two  candidate paths, and the controller does not
>> know what the node-address CSG1 will eventually generate. Maybe:
>>
>> Candidate path 1’ key:  <*BGP,RR1’s ASN, RR1’ BGP Router ID,
>> discriminator1*>
>>
>> Candidate path 2’ key:  <*BGP,RR2’s ASN, RR2’ BGP Router ID,
>> discriminator2*>
>>
>> The process described above will result in a waste of redundant candidate
>> paths on CSG1,
>>
>> At the same time, when CSG1 needs to announce the SR Policy information
>> to the controller through BGP LS, it needs to carry the keys of the
>> candidate path in it, and the controller cannot recognize these keys.
>>
>>
>>
>>
>>
>>
>>
>> To solve these problems,  We recommend carrying the Route Origin
>> Community (defined in RFC 4360) directly when the controller advertises BGP
>> routes.
>>
>> In this way, the key  of the CP is determined by the controller and will
>> not change during the advertisement of BGP routes.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *发件人:* Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
>> *发送时间:* 2020年5月18日 20:00
>> *收件人:* Robert Raszuk <robert@raszuk.net>
>> *抄送:* Chengli (Cheng Li) <c.l@huawei.com>om>;
>> draft-ietf-spring-segment-routing-policy@ietf.org; idr wg <idr@ietf.org>rg>;
>> SPRING WG <spring@ietf.org>rg>; Fangsheng <fangsheng@huawei.com>om>; stefano
>> previdi <stefano@previdi.net>
>> *主题:* RE: [Idr] Comments: Route Origin Community in SR
>> Policy(draft-ietf-spring-segment-routing-policy)
>>
>>
>>
>> Hi Robert,
>>
>>
>>
>> You are right that the “Originator” is not used in BGP best path and is
>> just for a tie-breaking logic in SRTE between paths from different
>> protocols and controllers. I doubt if there is a functional issue here.
>>
>>
>>
>> I thought that Chengli was bringing in some new/different requirement for
>> the “Originator” field for some deployment design. I haven’t seen a
>> response/clarification from him as yet, and so perhaps I misunderstood him
>> in which case we are ok here.
>>
>>
>>
>> Thanks,
>>
>> Ketan
>>
>>
>>
>> *From:* Robert Raszuk <robert@raszuk.net>
>> *Sent:* 30 April 2020 14:46
>> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>
>> *Cc:* Chengli (Cheng Li) <chengli13@huawei.com>om>;
>> draft-ietf-spring-segment-routing-policy@ietf.org; idr wg <idr@ietf.org>rg>;
>> SPRING WG <spring@ietf.org>rg>; Fangsheng <fangsheng@huawei.com>om>; stefano
>> previdi <stefano@previdi.net>
>> *Subject:* Re: [Idr] Comments: Route Origin Community in SR
>> Policy(draft-ietf-spring-segment-routing-policy)
>>
>>
>>
>> Hi Chengli and Ketan,
>>
>>
>>
>> Well I think (perhaps to your surprise) the current text is actually
>> correct.
>>
>>
>>
>> See the overall idea of section 2.4 is not to define the real source of
>> the candidate path. That is done in section 2.5 The idea here is to keep
>> multiple *paths or versions* of the candidate paths in the local system
>> uniquely.
>>
>>
>>
>> See if you continue reading section 2.6 demystifies the real objective:
>>
>>
>>
>>    The tuple <Protocol-Origin, originator, discriminator> uniquely
>>
>>    identifies a candidate path.
>>
>>
>>
>> So the real originator is encoded in discriminator and here it just means the peer candidate path was
>>
>> received from. And if you read on this entire exercise only servers best path selection as described in section 2.9.
>>
>>
>>
>> .... the following order until only one valid best path is selected:
>>
>>
>>
>>    1.  Higher value of Protocol-Origin is selected.
>>
>>
>>
>>    2.  If specified by configuration, prefer the existing installed
>>
>>        path.
>>
>>
>>
>>    3.  Lower value of originator is selected.
>>
>>
>>
>>    4.  Finally, the higher value of discriminator is selected.
>>
>>
>>
>> +
>>
>>       The originator allows an operator to have multiple redundant
>>
>>       controllers and still maintain a deterministic behaviour over
>>
>>       which of them are preferred even if they are providing the same
>>
>>       candidate paths for the same SR policies to the headend.
>>
>>
>>
>> Thx,
>> R.
>>
>>
>>
> On Thu, Apr 30, 2020 at 10:46 AM Ketan Talaulikar (ketant) <ketant=
>> 40cisco.com@dmarc.ietf.org> wrote:
>>
> Hi Cheng,
>>
>>
>>
>> I assume you are recommending the use of Route Origin Extended Community (
>> https://tools.ietf.org/html/rfc4360#section-5) for conveying the
>> “Originator” when the SR Policy update is propagated over eBGP sessions via
>> other eBGP/iBGP sessions instead of direct peering with the headend.
>>
>>
>>
>> I believe it does address the scenario you describe given that it is
>> expected that SR Policy propagation via BGP is happening within a single
>> administrative domain even if it comprises of multiple ASes.
>>
>>
>>
>> Also copying the IDR WG for inputs since this would likely need to be
>> updated in draft-ietf-idr-segment-routing-te-policy.
>>
>>
>>
>> Thanks,
>>
>> Ketan
>>
>>
>>
>> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Chengli (Cheng
>> Li)
>> *Sent:* 30 April 2020 07:34
>> *To:* draft-ietf-spring-segment-routing-policy@ietf.org
>> *Cc:* SPRING WG <spring@ietf.org>rg>; huruizhao <huruizhao@huawei.com>om>;
>> Fangsheng <fangsheng@huawei.com>
>> *Subject:* [spring] Comments: Route Origin Community in SR
>> Policy(draft-ietf-spring-segment-routing-policy)
>>
>>
>>
>> Hi authors,
>>
>>
>>
>> In section 2.4 of [draft-ietf-spring-segment-routing-policy-06],
>> introduced how the node-address of "Originator of CP(Candidate Path)" is
>> generated when the Protocol-Origin is BGP. It says:
>>
>>     “Protocol-Origin is BGP SR Policy, it is provided by the BGP
>> component on the headend and is:
>>
>>      o  the BGP Router ID and ASN of the node/controller signalling the
>> candidate path when it has a BGP session to the headend, OR
>>
>>      o  the BGP Router ID of the eBGP peer signalling the candidate path
>> along with ASN of origin when the signalling is done via one or  more
>> intermediate eBGP routers, OR
>>
>>      o  the BGP Originator ID [RFC4456] and the ASN of the
>> node/controller  when the signalling is done via one or more
>> route-reflectors over  iBGP session.”
>>
>>
>>
>> In the operator's network, in order to reduce the number of  BGP sessions
>> in controller and achieve scalability, the controller only establishes eBGP
>> peer with the RR. And the RR establishes iBGP peers with the headends.. As
>> mentioned in the draft, the headend will use the RR's Router ID as the CP's
>> node-address (the signaling is done via route transmission from RR to the
>> headend instead of route reflection).  The headend needs to carry the CP's
>> key when reporting the SR Policy status to the controller through BGP-LS.
>> And there is a problem that the controller may not recognize the key
>> because the node-address is generated by the RR node.
>>
>>
>>
>> For network robustness, two or more RRs are usually deployed. This will
>> introduce another problem.. When the same CP advertised by the controller
>> is delivered to the headend through different RRs, the headend cannot
>> distinguish whether it is the same CP because the node-address in the CPs'
>> key  comes from different RRs.
>>
>>
>>
>> To solve these problems,  We recommend carrying the Route Origin
>> Community (defined in RFC 4360) directly when the controller advertises BGP
>> routes.  In this way, the key  of the CP is determined by the controller
>> and will not change during the advertisement of BGP routes.
>>
>>
>>
>> Thanks,
>>
>> Cheng
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD