Re: [Idr] Mail regarding draft-ietf-idr-segment-routing-te-policy

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Tue, 09 July 2019 05:21 UTC

Return-Path: <ketant@cisco.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 D8A78120335 for <idr@ietfa.amsl.com>; Mon, 8 Jul 2019 22:21:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=jjSzBeVj; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=wc56kmlX
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 pr4aB9sKz-xH for <idr@ietfa.amsl.com>; Mon, 8 Jul 2019 22:21:25 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695FD1200EC for <idr@ietf.org>; Mon, 8 Jul 2019 22:21:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51966; q=dns/txt; s=iport; t=1562649685; x=1563859285; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HGbhPo8T+hrgKdRNp/AgIYEV0/V79x4ZMi6rzWMcBH8=; b=jjSzBeVjXcjnJ2zU06wrfBzoTc2q5b2Oornr0Rkwk84Rj/Br4gDiGPS8 o6w2uiHxtSwRUJI0lMSTuqHqzQKB6VzmZcJDeL+m/DlopEoSvfjDqtlbO bziCjNX97XD7URxU3RqsVRoNtp//9RjyTawb326Y7zwPvYKCH1wLrqkNX k=;
IronPort-PHdr: =?us-ascii?q?9a23=3AvRea/BSmuXsQMTsT/8t3HJwZt9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESUDNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOi83AM1ESHdu/mqwNg5eH8OtL1A=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAACiIyRd/5BdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwUBAQEBCwGBFC8pJwNqVSAECyiEHINHA4RSiXaCW36WSIE?= =?us-ascii?q?ugSQDUAQJAQEBDAEBGAEKCgIBAYRAAheCISM0CQ4BAwEBBAEBAgEFbYo3DIV?= =?us-ascii?q?KAQEBBAEBEBEKEwEBLAsBDwIBCBEEAQEhAQYDAgICJQsUCQgCBA4FCAwOgwG?= =?us-ascii?q?BHU0DHQEOnl8CgTiIYHGBMoJ5AQEFgTYCg0gYghIDBoE0AYteF4FAP4ERRoI?= =?us-ascii?q?XNT6CYQEBA4E+AQEgKwmCVDKCJot6gnaEfYhnjgIJAoIXhlaEbIhdgiyHIYQ?= =?us-ascii?q?MiFWBUI5ghhCPfQIEAgQFAg4BAQWBUDgqgS5wFTuCbIJBDBeBAwEIgkKFFIU?= =?us-ascii?q?/coEpi0aCQwEB?=
X-IronPort-AV: E=Sophos;i="5.63,469,1557187200"; d="scan'208,217";a="371808690"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Jul 2019 05:21:23 +0000
Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x695LN1l007602 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Jul 2019 05:21:23 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 9 Jul 2019 00:21:22 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 9 Jul 2019 01:21:21 -0400
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 9 Jul 2019 00:21:21 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G2Ythu9xJztHczkshCHCwjN5nx+sWGSVMUWL23FL95xTgyAIm2bhVKa9CQ5lx2GKPV18a/zgi7rxzcHIY4PG3jFghTfK6wfbsrZpy6hAE1Jsibcy+dnGZ0Np5deqbBkcnWF5WGvSNosISFnzqOuJ0OIotAxKzN5GlQNgZXZV63PHsRQ1zsX1rZSPPF+8Lxy7BCvpEVIgwiJJMRNw5VA+CXiuFqpsogBhcRogWkCFiICo3VF4P3hhpGTQmsdimXmkaMQPhjz+DwIwmFXxhNvKTWuiydYuTAGlFVvNMIEZJfxa4i5tIuFkSTu5ZBVS+d+2JlYWqXd9I5rfanDghgoYsg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HGbhPo8T+hrgKdRNp/AgIYEV0/V79x4ZMi6rzWMcBH8=; b=AIiHaoTIldHbCz3J3Qh9IEQ8tkpGUHbThpPlSey8j+cBkdWpw/tJFrixRN+IX5KJWStUh2/KMja2LGGBnXS8P4cv5Oo5M6xC+ZcmRFKdoKMYBa7Rz3gn0CWE6MN0V9qM4S6L5FOfTfippRLBSs+6hgh9bwIpqGzStxuU5vx/+h4xA89CiVdG8J3YGwEz9Dc9mSwvXM+B1r9NbbJjbVW+/mjroSHELtkIwFnwdtOpBhK/2rTJN1WaEWks8Yfyjr98L+bJ3Nz8QKj8FmPDcSNk6GHKeIjVtwfVZa1wfHzYnItAIyn3wvdM58rwA5vv7hbs5m6ebcNosiTRlpp9Y5J0Ng==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HGbhPo8T+hrgKdRNp/AgIYEV0/V79x4ZMi6rzWMcBH8=; b=wc56kmlXM3VIDqnnRAFoxCXQGizU9n59A54Ei3G9SHwIHJJvDTC0ITelFPHCVqQbxraMgVlgAMB22th9L18xHaKoBkrQJoqaAIMO9RldZAXrNWVvShCm57YdjgZVy6Lr11AesDwMwtGY961sKSjEd9eB6GCvY0E3iEo2Xqir0z0=
Received: from DM5PR11MB2027.namprd11.prod.outlook.com (10.168.103.22) by DM5PR11MB2058.namprd11.prod.outlook.com (10.168.107.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Tue, 9 Jul 2019 05:21:19 +0000
Received: from DM5PR11MB2027.namprd11.prod.outlook.com ([fe80::e83a:ff79:ed23:a9c]) by DM5PR11MB2027.namprd11.prod.outlook.com ([fe80::e83a:ff79:ed23:a9c%2]) with mapi id 15.20.2052.020; Tue, 9 Jul 2019 05:21:19 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Nandan Saha <nandan@arista.com>
CC: Gurusiddesh Nidasesi <gurusiddesh.nidasesi@ipinfusion.com>, "idr@ietf.org" <idr@ietf.org>, Chaitanya Varma <chaitanya.varma@ipinfusion.com>, "Ramanathan Selvamani" <ramanathan.selvamani@ipinfusion.com>
Thread-Topic: [Idr] Mail regarding draft-ietf-idr-segment-routing-te-policy
Thread-Index: AdT/KtjPP6BADXj+R+K+v5ydxRQvuQA+pdWgASkO/wAAL5Y2QAmaF82AAW1oLBAA6EWMgAAAlx7wADKle4AAAAxOAA==
Date: Tue, 9 Jul 2019 05:21:19 +0000
Message-ID: <DM5PR11MB20271F1F2E58B311121D5CA9C1F10@DM5PR11MB2027.namprd11.prod.outlook.com>
References: <993db9e45983acc9769af61bf786a6d6@mail.gmail.com> <SN6PR11MB284516BC1430BFFA5E494C0EC13B0@SN6PR11MB2845.namprd11.prod.outlook.com> <CAHhGMfGRgdDTam97sb5dYZQHBLLHpTj85yJ7oL5w7wrB3+q3jA@mail.gmail.com> <SN6PR11MB28451163BCFFD7E2A2DFBFA9C1320@SN6PR11MB2845.namprd11.prod.outlook.com> <CAHhGMfF3XvN4UhedzGSMSA_Qg9JHRp55Vw9enAzsmAh0BBmZ-Q@mail.gmail.com> <DM5PR11MB2027233E97E8949D36D48222C1FB0@DM5PR11MB2027.namprd11.prod.outlook.com> <CAHhGMfGF0kC27GZT4KXMJ835NEyT0kJ8FNCm663h5hW8Mga6Dw@mail.gmail.com> <DM5PR11MB2027BFDCB48266BF271063FFC1F60@DM5PR11MB2027.namprd11.prod.outlook.com> <CAE+itjch5GWWxxBa4rUD2qR_f187=fb-1YspC63UUKMT2hcxxA@mail.gmail.com>
In-Reply-To: <CAE+itjch5GWWxxBa4rUD2qR_f187=fb-1YspC63UUKMT2hcxxA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ketant@cisco.com;
x-originating-ip: [2001:420:c0e0:1002::41c]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1e010a8b-8922-4048-ab70-08d7042d467e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR11MB2058;
x-ms-traffictypediagnostic: DM5PR11MB2058:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: <DM5PR11MB20586B71340B2D92143588BDC1F10@DM5PR11MB2058.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0093C80C01
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(396003)(136003)(366004)(376002)(199004)(189003)(51914003)(86362001)(66574012)(6116002)(790700001)(11346002)(68736007)(446003)(8676002)(236005)(53936002)(81156014)(81166006)(6246003)(54896002)(55016002)(25786009)(6306002)(33656002)(486006)(76116006)(66476007)(64756008)(66556008)(14454004)(66946007)(71200400001)(71190400001)(6916009)(66446008)(476003)(73956011)(52536014)(74316002)(229853002)(7736002)(4326008)(478600001)(76176011)(99286004)(53546011)(2906002)(5660300002)(6436002)(6506007)(316002)(966005)(8936002)(9686003)(606006)(102836004)(54906003)(46003)(186003)(7696005)(14444005)(256004)(5024004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB2058; H:DM5PR11MB2027.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: OrnbP7yWvqe45awKPiXh1/t2JccjdbD5XIRLSQWWjTxo+8pf9a5bb0GkBwf72roPe5oOflJTm6lVNLRnOyyoN313ux724Ee+gerFsEiOpfnHICp1R39DVvi5DoH6A5Y8SNTfXqC44Z0yeAMmEHS/AoOPFbUH4hI9NmV+lY7ElSW7jp+cwi8MUaaA+eKC6+G8Dgo2DTvVnqIFsnXlPdsXznV1KVrwHUdHN7GRMOgzZzRYn2X8v3KUUTNxNIazQDjuCFA3C/2uQJHkAxZwanbUW1NYDywwd0kWmFqD8xCGRUds29mMpVF3HhpNiNVZGTEPJRM2UWarnyttQwkFK6UkUJXTK0SuW2Hv+Wn5gO+uNT0tQaTdjoABjjphOL+93070hx+smS01vJ50rm7pYENQkI5yq8pTCZUxx1hmQc3jQLc=
Content-Type: multipart/alternative; boundary="_000_DM5PR11MB20271F1F2E58B311121D5CA9C1F10DM5PR11MB2027namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1e010a8b-8922-4048-ab70-08d7042d467e
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 05:21:19.7629 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ketant@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB2058
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.27, xch-aln-017.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/4CkRFi7zmh_-mfIN6j1sR4fiOI0>
Subject: Re: [Idr] Mail regarding draft-ietf-idr-segment-routing-te-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: Tue, 09 Jul 2019 05:21:35 -0000

Agree Nandan and I’ve discussed this offline with one of the co-authors to address this.

Thanks,
Ketan

From: Nandan Saha <nandan@arista.com>
Sent: 09 July 2019 10:36
To: Ketan Talaulikar (ketant) <ketant@cisco.com>
Cc: Gurusiddesh Nidasesi <gurusiddesh.nidasesi@ipinfusion.com>; idr@ietf.org; Chaitanya Varma <chaitanya.varma@ipinfusion.com>; Ramanathan Selvamani <ramanathan.selvamani@ipinfusion.com>
Subject: Re: [Idr] Mail regarding draft-ietf-idr-segment-routing-te-policy

Hi Ketan,
Maybe it makes sense to reword this a little bit? The point about multiple RTs in the update is fine, but the confusion probably stems from "match one of the BGP identifiers"
If one or more route-targets are present, then at least one route  target MUST match one of the BGP Identifiers of the receiver in order
   to
If one or more route-targets are present, then at least one route  target MUST match the BGP Identifier of the receiver in order

Thanks,
Nandan
On Mon, Jul 8, 2019 at 10:46 AM Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>> wrote:
Hi Gurusiddesh,

The reason for allowing multiple RTs is if the same SR Policy needs to be delivered to multiple headend routers. It need not be read as a BGP router having more than one BGP identifier.

Thanks,
Ketan

From: Gurusiddesh Nidasesi <gurusiddesh.nidasesi@ipinfusion.com<mailto:gurusiddesh.nidasesi@ipinfusion.com>>
Sent: 08 July 2019 10:09
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Cc: Chaitanya Varma <chaitanya.varma@ipinfusion.com<mailto:chaitanya.varma@ipinfusion.com>>; idr@ietf.org<mailto:idr@ietf.org>; Ramanathan Selvamani <ramanathan.selvamani@ipinfusion.com<mailto:ramanathan.selvamani@ipinfusion.com>>
Subject: Re: [Idr] Mail regarding draft-ietf-idr-segment-routing-te-policy

Hi Ketan,

Thanks for the response.
Additionally, we have more queries as follows:


The draft says that
"One or more IPv4 address format route-target extended community

      ([RFC4360<https://tools.ietf.org/html/rfc4360>]) attached to the SR Policy advertisement and that
      indicates the intended head-end of such SR Policy advertisement."

Here one or more RTs are attached to match specific headend?

" If one or more route-targets are present, then at least one route  target MUST match one of the BGP Identifiers of the receiver in order  for the update to be considered usable."
Can a BGP peer have more than one BGP identifier?


On Wed, Jul 3, 2019 at 7:29 PM Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>> wrote:
Hi Gurusiddesh,

The purpose of the RT is to indicate the specific headend for which the SR Policy is for. So I am not sure of the scenario where multiple RTs will be associated with a single update.

Even if it were, I am not sure we normally strip out RTs automatically without some specific route policy being applied.

Thanks,
Ketan

From: Gurusiddesh Nidasesi <gurusiddesh.nidasesi@ipinfusion.com<mailto:gurusiddesh.nidasesi@ipinfusion.com>>
Sent: 26 June 2019 12:56
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Cc: Chaitanya Varma <chaitanya.varma@ipinfusion.com<mailto:chaitanya.varma@ipinfusion.com>>; idr@ietf.org<mailto:idr@ietf.org>; Ramanathan Selvamani <ramanathan.selvamani@ipinfusion.com<mailto:ramanathan.selvamani@ipinfusion.com>>
Subject: Re: [Idr] Mail regarding draft-ietf-idr-segment-routing-te-policy

Hi Ketan,

We have some more doubts as follows:


"Typically, a controller defines the set of policies and advertise

   them to policy head-end routers (typically ingress routers).  The

   policy advertisement uses BGP extensions defined in this document.

   The policy advertisement is, in most but not all of the cases,

   tailored for a specific policy head-end.  In this case the

   advertisement may sent on a BGP session to that head-end and not

   propagated any further."


If controller sends multiple unique RTs in the same Update message,
1. Once the SR policy reaches the Headend, should we strip down that particular RT to avoid advertising it further?



Thanks

Gurusiddesh V N







On Wed, May 8, 2019 at 3:58 PM Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>> wrote:
Hi Gurusiddesh,

Please check inline below

From: Gurusiddesh Nidasesi <gurusiddesh.nidasesi@ipinfusion.com<mailto:gurusiddesh.nidasesi@ipinfusion.com>>
Sent: 07 May 2019 17:11
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Cc: Chaitanya Varma <chaitanya.varma@ipinfusion.com<mailto:chaitanya.varma@ipinfusion.com>>; idr@ietf.org<mailto:idr@ietf.org>
Subject: Re: [Idr] Mail regarding draft-ietf-idr-segment-routing-te-policy

Hi Ketan,

Thanks for the quick response.
Additionally, we have more queries as follows

"Alternatively, a router (i.e., a BGP egress router) advertises SR
   Policies representing paths to itself.  In this case, it is possible
   to send the policy to each head-end over a BGP session to that head-
  end, without requiring any further propagation of the policy."

How does an egress router advertise SR policies representing paths to itself?
[KT] By setting endpoint to it’s own router-id in the NLRI and setting the ingress router’s router-id in the router-target extended community.
Is it done through BGP configuration or any other trigger?
[KT] This would be implementation specific based on the use-case/workflow.

In the above case how ERO (SID-List) is calculated?
[KT] This is again implementation specific. It could be done by some TE module on the egress BGP router that has topology visibility from the ingress router to itself. It would be kind of reverse of how a headend computes a path from itself to an endpoint – this is the endpoint computing path to itself from some headend.
Thanks,
Ketan

Regards
Gurusiddesh V N

On Wed, May 1, 2019 at 7:34 PM Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>> wrote:
Hi Chaitanya,

Please check inline below.

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Chaitanya Varma
Sent: 30 April 2019 13:34
To: idr@ietf.org<mailto:idr@ietf.org>
Cc: Gurusiddesh Nidasesi <gurusiddesh.nidasesi@ipinfusion.com<mailto:gurusiddesh.nidasesi@ipinfusion.com>>
Subject: [Idr] Mail regarding draft-ietf-idr-segment-routing-te-policy

Hi,

I have couple of queries from the below draft.

https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05

  “ Typically, a controller defines the set of policies and advertise
   them to policy head-end routers (typically ingress routers).”

How do we communicate SR policies from controller? Is it through BGP-SR session or PCEP session.
[KT] This draft is all about using BGP for signalling SR Policies from a controller to the head-end routers. So yes (b) below.

a. If it is through PCEP session what happens if the PCC is non-headend?
b. If it is through BGP-SR what is the role for PCEP between PCE and PCC?
[KT] PCEP is another flavour for instantiation of SR Policies. Yet another option is using netconf/yang or another method for provisioning. This draft is about using BGP and PCEP is not required.


  “ Moreover, one or more route-target SHOULD be attached to the
   advertisement”

How Route-target should be attached to a SR-NLRI update?
[KT] As Route Target Extended Communities attribute – ref sec 1 of the draft.

Is it done through local configuration or picked up based on some dynamic parameter?
[KT] It is done by the controller and may be done via local config – either along with the SR Policy or route policy or even dynamically based on the head-end address. This would be implementation specific.

Thanks,
Ketan

Appreciate if you can help here.


Regards,
Chaitanya


..


--
Thanks,
Gurusiddesh V N

.


--
Thanks,
Gurusiddesh V N

.


--
Thanks,
Gurusiddesh V N

.
_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr