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

Gyan Mishra <hayabusagsm@gmail.com> Mon, 01 June 2020 21:28 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 B74F53A1599; Mon, 1 Jun 2020 14:28:34 -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 7YpDxOWrsUmz; Mon, 1 Jun 2020 14:28:31 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 88BE13A159A; Mon, 1 Jun 2020 14:28:31 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id j8so8522620iog.13; Mon, 01 Jun 2020 14:28:31 -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=BCtYkwv4IBhcD4AbOcH7Kgq462lHSNokt1g/zqXf2a8=; b=WOI6XD9dT32E0wQaFMlWSCUt862quByv47lY1VXRrhLkX7TsoQtRdLnMk9p4CymkUK CLZ8qUEq9lXFAMacLTnR8iZG/+HG6kdtl3qNmbLFcpqdU+e8EFzLJ+8Gq/tkw87pQL7t e4pfoVKrSZd/dGmqpyNVo4GOf3v/UcEXcJ4xzyvoB/M+IO+6p6bTRmt1xC6EYaPLEE49 sBUid9lvuG33uFlhQbVSeQHCRa+owhXXmumxYK9sxx9Jv7JNjh3tVs34WAYemckfQc2c I5kuqEyqWUbfojHlIc8gqY9ycxexjQwNf7qP8bWFGqNf2S8Vjnr/A7fm1TqvC7mktRKg jspw==
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=BCtYkwv4IBhcD4AbOcH7Kgq462lHSNokt1g/zqXf2a8=; b=lr02b7VxkFaogndIdTu/E++ZLOx/cmRcR3hPvXDTrTO1kADOcfqbpTfrYGAB1GzMjY IYEWxJTQa569KkLIaBU4wFrE9KYmcnMBFx59lPw6AdQ1eVM7JLfTTy7ZEZi0CXVAEz76 ptLGdVDqEjWrdRIMrXI65JOp1r+/0pV2ZC9v4eYiwzS9Do6R3eXsjk/7AuOB2oZJwrS4 3ITRQimH5LkLq6d5vYzE3jxLiz/H+I9cC9KpkszBo6A4yqWDUqiQPZOJAQoPWOVU5NN+ 7DGxhJo5e84S+6bcNIa8ZBE5rfIGRCFWnbnjVcYXmQMZrHlSXn4sxFQnl2u9alk8tR9N pWyw==
X-Gm-Message-State: AOAM531WQtT1Wrac4AfQlTqJ7pqCakjhtA1rrB5imTBoguV1gclm+mpg isLAyAE6wlMrAY1cLuL5WzBcWxLDCf4l0930HDo=
X-Google-Smtp-Source: ABdhPJwG9nIb94CXRKpC9N0ZcR2T1s5n8UbLlMmpoWaismvF3gP4nDWoMqX9ztVbBBk+LKGdsVlOuco7iRBcQk9DLpg=
X-Received: by 2002:a5d:914d:: with SMTP id y13mr20790847ioq.48.1591046909498; Mon, 01 Jun 2020 14:28:29 -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> <C7C2E1C43D652C4E9E49FE7517C236CB02A57CCB@dggeml529-mbx.china.huawei.com> <CABNhwV08s50W34FZs2UvpUM2nXTD_ThN_FAJEQ+rGjEOO1X+Gw@mail.gmail.com> <MW3PR11MB45700400C0B10EF7A4C8C1B3C18A0@MW3PR11MB4570.namprd11.prod.outlook.com>
In-Reply-To: <MW3PR11MB45700400C0B10EF7A4C8C1B3C18A0@MW3PR11MB4570.namprd11.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 1 Jun 2020 17:28:18 -0400
Message-ID: <CABNhwV3PXr+LfF8RLzoXMzL=gcrf5ibFjWSa7kp9oAkDVN9xUA@mail.gmail.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Cc: "Chengli (Cheng Li)" <c.l@huawei.com>, Fangsheng <fangsheng@huawei.com>, Robert Raszuk <robert@raszuk.net>, SPRING WG <spring@ietf.org>, "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/alternative; boundary="000000000000dc985d05a70c79cf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/AO6elp2lcnlZvI8Kd31ajBFQ0Io>
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: Mon, 01 Jun 2020 21:28:35 -0000

Hi Ketan

Thank you for the response.  I believe that does answer the general
questions from a draft specification perspective.   I had not read all the
way through the draft so missed that section.  I do have some Cisco
specific SR-TE questions that I will ping you off list.

Kind regards

Gyan

On Mon, Jun 1, 2020 at 10:59 AM Ketan Talaulikar (ketant) <ketant@cisco.com>
wrote:

> Hi Gyan,
>
>
>
> Your question is a bit orthogonal to the thread and my apologies if I did
> not get it right.
>
>
>
> Could you please check whether the following section clarifies what you
> were looking for?
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-07#section-8.4
>
>
>
> The draft does not talk about the application of a specific Color Extended
> Community attribute to all routes belonging to a specific VRF since that is
> more of a local policy or implementation matter.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* 01 June 2020 19:17
> *To:* Chengli (Cheng Li) <c.l@huawei.com>
> *Cc:* Fangsheng <fangsheng@huawei.com>om>; Ketan Talaulikar (ketant) <
> ketant@cisco.com>gt;; Robert Raszuk <robert@raszuk.net>et>; SPRING WG <
> spring@ietf.org>gt;; draft-ietf-spring-segment-routing-policy@ietf.org; idr
> wg <idr@ietf.org>rg>; stefano previdi <stefano@previdi.net>
> *Subject:* Re: [spring] [Idr] Comments: Route Origin Community in SR
> Policy(draft-ietf-spring-segment-routing-policy)
>
>
>
>
>
> Ketan
>
>
>
> Thanks for sharing this draft.
>
>
>
> This draft below is the SR-TE policy itself but the piece I was missing
> was the BGP interaction between SR-TE and new SAFI to advertise SR-TE
> policy into BGP which is the critical component of the per VRF coloring
> schema to steer L3 vpn traffic.
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-07
>
>
>
>
>
> On Mon, Jun 1, 2020 at 3:25 AM Chengli (Cheng Li) <c.l@huawei.com> wrote:
>
> Hi Ketan,
>
>
>
> Sorry for my delay, I saw the update, and it has addressed my comments,
> many thanks.
>
>
>
> Best,
> Cheng
>
>
>
>
>
> *From:* Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
> *Sent:* Monday, May 18, 2020 8:00 PM
> *To:* Robert Raszuk <robert@raszuk.net>
> *Cc:* 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>
> *Subject:* 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/>
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
> *Silver Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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