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

Przemyslaw Krol <> Wed, 20 November 2019 21:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BDBC120233 for <>; Wed, 20 Nov 2019 13:39:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7-1H93d_eLV9 for <>; Wed, 20 Nov 2019 13:39:25 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::c34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A8C49120241 for <>; Wed, 20 Nov 2019 13:39:25 -0800 (PST)
Received: by with SMTP id y18so558330ywk.1 for <>; Wed, 20 Nov 2019 13:39:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z6imC0kkeGkZBUOLAsvInHb7Wji21wJ01k9J2K1EqBQ=; b=cUYlD4mIgPPMLZTtaUVcCrATklsL7c4XjOJkTuUrRTcz4xqXmxMtg0F378KZKKOHkh ZhOj+C2KNm+XxYTH7xb7UERLCkPRBBwgFJpKvPSHahM+mw687KhmyiLRA1Diw+OjmgBX zkzfTx+csYmS+VGB8n0uUcgqZPOswhJpKUaWr5w5aQOZ9KSW+/qdRqKOfG+gI7zJ26/r R/nifI735C+IH0kOITNCp4Jv/VGZIEz7Kj7Vz9bShL3a1gY7qY03Hmd2L+M8MkcigoiP ZlN1FvqHao/ssyC/YW4C0cB99glm6LDNf+YoI12LG1g8AZG7bwzp4OAn/cADD9yRzFmC 49Kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z6imC0kkeGkZBUOLAsvInHb7Wji21wJ01k9J2K1EqBQ=; b=ay5R9mpW58FcOx7DNzlgaygCa4SsfqqJZPNUuKPaMM89hR7HtbGZ9gnuheUbTzPtxt T5D1ilOZhlM965mRJhbtObfFd4KbIFvQ9C/r+Jr+59uhzehelldTUZtKRI6x/Xjg4cnY F00ttTeVOOxrQp6FFbHrlZsxQLjxIo+MzzKOoSQ4VNdW1t4oOkaPcn6yzVg8XzUFGHYV n9AQa01eG6dTT898kL/qbGgKKbiTnDRHKRQhP+W6tts/ShgS6abdFerTAKTu4QjMnl/5 Ea3VR88MBpp8P1CbJvWWSHsetHFsuAlfoP7uFCPVd8YWbd+XpuogzG4EK4URB4vJIuOy kiiw==
X-Gm-Message-State: APjAAAXM9Wt+xlTca+Uu0wdAfPytJ6SZbYs435NQbt+9kTiVi7MU5ecM LmjS01+kEuBwhbbuUQWR8ZGb0QZuT8CQ4V1P61F/Mw==
X-Google-Smtp-Source: APXvYqy85gLMMDPKck5yOOjP7mObgevpRtO6Y8RlXnd1wj5RiXzvXwaUNRKNkWnKMIstzyIAYQG/oskFsGll0tEg+pU=
X-Received: by 2002:a81:a11:: with SMTP id 17mr3308794ywk.368.1574285964209; Wed, 20 Nov 2019 13:39:24 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Przemyslaw Krol <>
Date: Thu, 21 Nov 2019 05:38:47 +0800
Message-ID: <>
To: Robert Raszuk <>
Cc: "Ketan Talaulikar (ketant)" <>, "" <>, Prakash Badrinarayanan <>, Manoharan Sundaramoorthy <>
Content-Type: multipart/alternative; boundary="000000000000ac4d2e0597ce032c"
Archived-At: <>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-08.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Nov 2019 21:39:28 -0000

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

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.


On Wed, Nov 20, 2019 at 10:18 PM Robert Raszuk <> 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 |