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

Robert Raszuk <robert@raszuk.net> Thu, 30 April 2020 09:15 UTC

Return-Path: <robert@raszuk.net>
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 BBD6F3A0C5C for <idr@ietfa.amsl.com>; Thu, 30 Apr 2020 02:15:50 -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=ham 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 mRqnIrMq5xzD for <idr@ietfa.amsl.com>; Thu, 30 Apr 2020 02:15:48 -0700 (PDT)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 4F2E93A0C5A for <idr@ietf.org>; Thu, 30 Apr 2020 02:15:48 -0700 (PDT)
Received: by mail-ej1-x62b.google.com with SMTP id gr25so4065438ejb.10 for <idr@ietf.org>; Thu, 30 Apr 2020 02:15:47 -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=PtJ8Y5t/uc1KMCEev/xmVfpWJ9Q+yE/eBSH6qJSO//s=; b=Udjm/CobZca8comyFOAKP7LCe+usUasSbXRcq7bPo0TGmRAiHqdg2hrRphmpPpqnQ4 Q22tgyoTQNAPwnV0nKofKoBqUXo1Jb4ntg6hTWp1GkxPvjBXthBbhhKY7n4r43smrs1G CXftk3LhKI7NuzN9LTogOnjXlYlGWRFrRzuETqvVhtG1e3OYj1JmqhAobPUXFttRRKK9 sU792EwAY8hK8vEc2dV2KE/BytEPWfu4GYvz0pprUrlLH0XlNEhyBMquxvCU1lOVcPM7 jSqxxv/R76mbHdmKfdEHto6XTm1As1sdogPI1LNrq2ysIhs49O9+d2AHyV2GtKkw17P5 grpQ==
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=PtJ8Y5t/uc1KMCEev/xmVfpWJ9Q+yE/eBSH6qJSO//s=; b=VEQvbjK0y+NGEA37UrMtWLDilJjlLgu8TyWRAHheuwYL/Jjn321iyFVF0HBlMEyfhw pxcmUgTw70RgN6gFQfIqJ+oRw+Xw8YbhOXNB2RqTzMVoG6JwuEPLc9bDLZgE0q+B8SqR 9DjtrLEJZw3Yd1hq60iyemsDkTSqUWZBKAhVFYJqfJuWMI2ARy93u9M9rmZa02mJU6uw ncEIn0ax5uknltY5zv2ArMdrcxuf2H8dyVkPGyCblWbl26P2KUsvc1ficvlwT7kTWeRc vlFbXB4ztdZ8dir8FA8rE5oRL+YVqQDdC6N5sYAHXBmhSLbOyS4TwiWbDDh4u23hDXAX r0Ow==
X-Gm-Message-State: AGi0PuYWb0BvZJeRKyonAwizPLeO5UyrHfW0ZYIrpVZesU9AwTeEWsDd pcOg+yBbs/WXtskWfr10vCdyqQgtd9Rv45grYwNhPA==
X-Google-Smtp-Source: APiQypK2FH3dmDiT0wW6Zn6nG+6nphdYbtrRdOKbnex7r/hDZCST1huTuvZt+PBt8KL1DzkE9lv8Cd5L1dc3lZxVYDA=
X-Received: by 2002:a17:906:a418:: with SMTP id l24mr1805095ejz.362.1588238146279; Thu, 30 Apr 2020 02:15:46 -0700 (PDT)
MIME-Version: 1.0
References: <C7C2E1C43D652C4E9E49FE7517C236CB029FAC88@dggeml529-mbx.china.huawei.com> <MW3PR11MB45702B49025A293583346F36C1AA0@MW3PR11MB4570.namprd11.prod.outlook.com>
In-Reply-To: <MW3PR11MB45702B49025A293583346F36C1AA0@MW3PR11MB4570.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 30 Apr 2020 11:15:36 +0200
Message-ID: <CAOj+MMGbjvgn6VL3dKviuxzNNRk0pwFkBOTJUz15D8iSM9=-Rw@mail.gmail.com>
To: "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>
Cc: "Chengli (Cheng Li)" <chengli13@huawei.com>, "draft-ietf-spring-segment-routing-policy@ietf.org" <draft-ietf-spring-segment-routing-policy@ietf.org>, idr wg <idr@ietf.org>, SPRING WG <spring@ietf.org>, Fangsheng <fangsheng@huawei.com>, stefano previdi <stefano@previdi.net>
Content-Type: multipart/alternative; boundary="000000000000873daa05a47e8205"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/K3Tk4cGWkSy0z0jVcq1iDJ_uO3A>
Subject: Re: [Idr] 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, 30 Apr 2020 09:15:51 -0000

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
>