Re: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-08.txt

Przemyslaw Krol <pkrol@google.com> Thu, 21 November 2019 04:30 UTC

Return-Path: <pkrol@google.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 5CD88120963 for <idr@ietfa.amsl.com>; Wed, 20 Nov 2019 20:30:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.498
X-Spam-Level:
X-Spam-Status: No, score=-17.498 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 51rfqBIoeH_Z for <idr@ietfa.amsl.com>; Wed, 20 Nov 2019 20:30:21 -0800 (PST)
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 3B74B120965 for <idr@ietf.org>; Wed, 20 Nov 2019 20:30:21 -0800 (PST)
Received: by mail-yb1-xb2c.google.com with SMTP id i3so945284ybe.12 for <idr@ietf.org>; Wed, 20 Nov 2019 20:30:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oV0FCbqd5ioMQ9ZAuldwSw2P6hPh/qkJNZdve6fNjsY=; b=OJhd6nN+WP2vYJPrpqjle9iRzoL6xNvAqLEWeBNrHuoxNLldbyHvqPjWSVI0HjknxH ps9LmGkPkcgx5wT4iH3FiUBVizUuR+iMngoA85A7c9qQh5qmC5ElJ+ZLUyui4acqR7RS DnPqkfxirvRyxxQuEIxP4324GZPrBQTlf9KNTX/edwWlKQkF3DmkygVyjqKTy0Gt1aFn IMh0GrG+DCXUAPUIFGOPmEaw1ZWEMRC5p87JyfSEGb1SCp4m4+YMsH20cI2h/bSGTH1J yEwd/aOF3/s13gXtW1Hs2zJHo78Gd+ohcqDgEtpsj41Be+mqpjOwqypx2YNZ+F5eHHWK mQJg==
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=oV0FCbqd5ioMQ9ZAuldwSw2P6hPh/qkJNZdve6fNjsY=; b=bkDrc0edm4G/wR21kM39CW2WHy9MGAFHkIOai/tFWxho8mXKcACRrILcppCQN8/nWI p2CSJGzazVRE0hxjeAVOAz6a9vEP4F1Zcsz7De7U5fHVUvzv08AieK3NdKAGgCC+ocDG josPsSU1VWEVWPy6V+uQQ2uEDFHn4HOPLJpxIm8wswaqFkJN9kSlvR5NsXeIwtc0ykgj S2txJyLAVJ+c/h4XWpr/nJw/H+QmIbnUuN5aWMiOt6f4rH9B3gPk6IGnEZ7fYXEe2IFm fagM9pIgMNMhAFU0SGld+tiSSQ07DqitqiqElnxWF0amWDvL4SebSxZc6yRaUVKQjdak iGsg==
X-Gm-Message-State: APjAAAVEEIl0gjKLd9A4ILOjhfA8PpKAjMo5qRRLILMXJhvWzNZiCJdT kfVJqABEHEPRfgcVkVVmvmzuscFpmoYHFTGjiwUiaA==
X-Google-Smtp-Source: APXvYqy0vfHlMLfRqIuX8AuDZAkbH4D1IITgfnV5NzkzbkmLHAAPqVuoINEyBjW900Wv1ludU/ohEZZk/viVwWVV3Uw=
X-Received: by 2002:a25:758a:: with SMTP id q132mr4732444ybc.459.1574310619703; Wed, 20 Nov 2019 20:30:19 -0800 (PST)
MIME-Version: 1.0
References: <157414471256.14003.6244444687150312939@ietfa.amsl.com> <CY4PR11MB1541D63781E529E2B2613F05C14C0@CY4PR11MB1541.namprd11.prod.outlook.com> <CAE+itjeJzygag3K4bA=KpDQgNie7shG8Z47YpMjfjMFF7aq=Tg@mail.gmail.com> <CY4PR11MB15414543EC96BB90BC1167D8C14C0@CY4PR11MB1541.namprd11.prod.outlook.com> <CACH2EkUjd6DDbD9m+rEsAzi+OL1+Q=Q0jEfhPej7d2N73wnL7Q@mail.gmail.com> <CAOj+MMF81zQbnb3vNBQfmEW6_wB4L3X9TV=NQNrhZCZya9+tJg@mail.gmail.com> <CACH2EkUfMgQK8rEtPKR_R1ubPz4yi_X=Cd4_8OFsz5hDhSjWxQ@mail.gmail.com> <CY4PR11MB154160CA1383D9E9B1023BC2C14F0@CY4PR11MB1541.namprd11.prod.outlook.com> <CAE+itjeNFAYW1D8wy2cWjXt8C2bnE=9V1t4QHKVJnYTRaKfHUQ@mail.gmail.com> <CY4PR11MB154127D96A0D27807D095199C14E0@CY4PR11MB1541.namprd11.prod.outlook.com>
In-Reply-To: <CY4PR11MB154127D96A0D27807D095199C14E0@CY4PR11MB1541.namprd11.prod.outlook.com>
From: Przemyslaw Krol <pkrol@google.com>
Date: Thu, 21 Nov 2019 12:29:41 +0800
Message-ID: <CACH2EkX1w=irCcjbxNw9Vp_L50hV8WnjkTRZ+gy0yN1tPasxEQ@mail.gmail.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Cc: Nandan Saha <nandan@arista.com>, Robert Raszuk <robert@raszuk.net>, "idr@ietf.org" <idr@ietf.org>, Prakash Badrinarayanan <prakash@arista.com>, Manoharan Sundaramoorthy <manoharan@arista.com>
Content-Type: multipart/alternative; boundary="000000000000415cd00597d3c1c4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/9R5yq25CgvNiz4-sM6bd2G1fmpQ>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-08.txt
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 Nov 2019 04:30:23 -0000

Thanks folks.

On Thu, Nov 21, 2019 at 12:06 PM Ketan Talaulikar (ketant) <ketant@cisco.com>
wrote:

> Hi Nandan,
>
>
>
> Yes. That is correct.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Nandan Saha <nandan@arista.com>
> *Sent:* 21 November 2019 12:00
> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>
> *Cc:* Przemyslaw Krol <pkrol@google.com>; Robert Raszuk <robert@raszuk.net>;
> idr@ietf.org; Prakash Badrinarayanan <prakash@arista.com>; Manoharan
> Sundaramoorthy <manoharan@arista.com>
> *Subject:* Re: [Idr] I-D Action:
> draft-ietf-idr-segment-routing-te-policy-08.txt
>
>
>
> Hi Ketan/PK,
>
>
>
> On Thu, Nov 21, 2019 at 4:57 AM Ketan Talaulikar (ketant) <
> ketant@cisco.com> wrote:
>
> Hi PK,
>
>
>
> I will make the text change for the community part as discussed below in
> the next update.
>
> Just to confirm, we're not treating both RT_TGT and NO_ADV  being present
> as an error, right? The update will only be to clarify that both are
> allowed together.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Przemyslaw Krol <pkrol@google.com>
> *Sent:* 21 November 2019 05:39
> *To:* Robert Raszuk <robert@raszuk.net>
> *Cc:* Ketan Talaulikar (ketant) <ketant@cisco.com>; idr@ietf.org; Prakash
> Badrinarayanan <prakash@arista.com>; Manoharan Sundaramoorthy <
> manoharan@arista.com>
> *Subject:* Re: [Idr] I-D Action:
> draft-ietf-idr-segment-routing-te-policy-08.txt
>
>
>
> Hi Robert,
>
>
>
> Why ? IMO when both present is a valid case as RT can be used locally for
> import as well. RT ext-community and NO_ADV community are pretty orthogonal
> and serve different purposes.
>
>
>
> That's a good point, although in SRTE, NO_ADVERTISE community has a
> special meaning on top of the "normal" propagation limitation.  Draft says
> 'either OR' so, in my opinion, this implies 'AND' is not acceptable. If
> that's the case, then NLRI should be dropped. If, on the other hand, both
> are acceptable, then it should probably state 'either RT or NO_ADVERTISE ot
> both'.
>
>
>
> Say when you are on RR suppressing IBGP would be a spec bug :).
>
>
>
> Fair enough. I was reading the previous version as 'by default don't
> propagate but you may' and was only curious why IBGP vs EBGP distinction
> was made in this version. Security aspect does sound like a good
> justification for it.
>
>
>
> thanks,
>
>
>
>
>
> On Wed, Nov 20, 2019 at 10:18 PM Robert Raszuk <robert@raszuk.net> wrote:
>
> Przemek,
>
>
>
> and clearly states the behavior when both are missing (policy not
> accepted).. Do you see a value in stating the behavior when both are
> present? Based on the above wording this would deem policy not acceptable
> and in consequence neither accepted locally not propagated down (must not
> accepted, not necessarily usable, in order to propagate as stated in the
> following section). Should it be clearly stated as erroneous condition?
>
>
>
> Why ? IMO when both present is a valid case as RT can be used locally for
> import as well. RT ext-community and NO_ADV community are pretty orthogonal
> and serve different purposes.
>
>
>
> 4.2.4. Propagation of an SR Policy
>
>
>
> It seems that the original wording was referring to just BGP when
> addressing the default propagation. In the current version, there is a
> distinction between EBGP (do not propagate) and IBGP (propagate). What is
> the reason for such distinction?
>
>
>
> Say when you are on RR suppressing IBGP would be a spec bug :).
>
>
>
> Thx,
>
> R.
>
>
>
>
>
>
>
>
> --
>
> Przemyslaw Gniewomir "PK" Krol |
>
>   Network Engineer
>
> ing | pkrol@google.com
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>

-- 
Przemyslaw Gniewomir "PK" Krol |   Network Engineer ing | pkrol@google.com